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Abstract 

A  revolution  in  earthmoving,  a  $100  billion  industry,  can  be  achieved  with  three  components: 
the  GPS  location  system,  sensors  and  computers  in  earthmoving  vehicles,  and  SITE 
CONTROLLER,  a  central  computer  system  that  maintains  design  data  and  directs  operations. 
The  first  two  components  are  widely  available;  I  built  SITE  CONTROLLER  to  complete  the 
triangle  and  describe  it  here. 

Civil  engineering  challenges  computer  scientists  in  the  following  areas:  computational 
geometry,  large  spatial  databases,  floating-point  artihmetic,  software  reliability, 
management  of  complexity,  and  real-time  control.  SITE  CONTROLLER  demonstrates  that  most 
of  these  challenges  nnay  be  surmounted  by  the  use  of  state-of-the-art  algorithms,  object 
databases,  software  development  tools,  and  code-generation  techniques.  The  system  works  well 
enough  that  Caterpillar  was  able  to  use  SITE  CONTROLLER  to  supervise  operations  of  a  160-ton 
autonomous  truck. 

SITE  CONTROLLER  assists  civil  engineers  in  the  design,  estimation,  and  cot\struction  of 
earthworks,  including  hazardous  waste  site  remediation.  The  core  of  SITE  CONTROLLER  is  a 
site  modelling  system  that  represents  existing  and  prospective  terrain  shapes,  road  and 
property  boundaries,  hydrology,  important  features  such  as  trees,  utility  lines,  and  general  user 
notations.  Around  this  core  are  analysis,  simulation,  and  vehicle  control  tools.  Integrating 
these  modules  into  one  program  enables  civil  engineers  and  contractors  to  use  a  single  interface 
and  database  throughout  the  life  of  a  project. 

This  area  is  exciting  because  so  much  of  the  infrastructure  is  in  place.  A  snail  effort  by 
computer  scientists  could  cut  the  cost  of  earthmoving  in  half,  enabling  poor  countries  to  build 
roads  aiKl  rich  countries  to  clean  up  hazardous  waste. 

This  report  is  a  revised  version  of  a  thesis  submitted  to  the  Department  of  Electrical 
Engineering  and  Computer  Science  in  February,  1993,  in  partial  fulfillment  of  the  requirements 
for  the  degree  of  Master  of  Science. 

This  report  describes  research  done  at  the  Artificial  Intelligence  Laboratory  of  the 
Massachusetts  Institute  of  Technology.  Support  for  this  research  is  provided  in  part  by  the 
Advanced  Research  Projects  Agency  of  the  Department  of  Defense  under  Office  of  Naval 
Research  contract  N0(X)14-92-J-4097  and  by  the  National  Science  Foundation  under  grant  number 
MlP-9001651. 
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1 .  What  is  Site  Controller? 


Advances  in  computer  systems,  computational  geometry  algorithms,  and  location  systems  have 
made  computer-aided  earthmoving  feasible.  Compared  with  traditional  techniques,  computer 
control  should  cut  the  cost  of  earthmoving  by  50-75%.  The  three  principal  components  required 
to  effect  a  revolution  in  earthmoving  are  the  following;  a  central  computer  system  that 
maintains  design  data  and  directs  operations;  a  location  system  that  can  determine  the  position 
of  earthmoving  vehicles  in  real  time;  and  on-vehicle  computers  that  assist  the  operator  and/or 
directly  control  implements. 

Location  systems  and  on-vehicle  computers  are  available  today.  1  built  SITE  CONTROLLER,  an 
example  of  the  critical  missing  component,  in  order  to  underline  the  fact  that  computer-aided 
earthmoving  is  feasible  today.  SITE  CONTROLLER  is  a  Common  Lisp  program  that  assists  civil 
engineers  in  the  design,  estimation,  and  construction  phases  of  earthmoving  projects.  The  core  of 
SITE  CONTROLLER  is  a  site  modelling  system  that  represents  the  following:  existing  and 
prospective  terrain  shapes;  road  and  property  boundaries;  hydrology;  important  features  such 
as  trees  and  utility  lines;  and  general  user  notations.  Around  this  core  are  analysis,  simulation, 
and  vehicle  control  tools. 

Terrain  is  represented  by  surfaces  interpolated  through  triangulated  sets  of  points  of  known  el¬ 
evation.  The  most  basic  surface  model  simply  postulates  a  plane  for  each  triangle,  resulting  in 
a  faceted  surface  like  that  of  a  cut  gemstone.  When  smooth  contour  lines  are  desired,  a  C^ 
surface  model  is  computed  by  making  each  triangle  a  nine-parameter  polynomial  surface  and 
matching  up  first  derivatives  at  triangle  borders.  Existing  topography  can  be  entered  in  the 
form  of  surveyed  points  while  prospective  topography  is  captured  from  user-sketched  contour 
lines. 

Analysis  software  consists  primarily  of  procedures  that  calculate  the  interaction  between  exist¬ 
ing  and  prospective  surfaces:  Where  would  one  have  to  excavate  and  fill  to  achieve  a  specified 
roadbed?  How  much  earth  would  have  to  be  trucked  onto  the  site  to  build  this  foundation? 
What  would  the  site  look  like  after  certain  design  ideas  have  been  adopted? 

Simulation  software  allows  the  user  to  plan  earthmoving  activities,  then  watch  them  progress 
in  simulation  and  see  the  evolution  of  terrain  shape.  This  provides  a  basis  for  accurate 
estimation  of  construction  costs.  Hand-in-glove  with  the  simulation  software  is  real-time 
vehicle  communication  and  control.  Site  model  information  to  aid  equipment  operators  is  sent 
over  radio  modems  while  vehicle  location  and  operation  information  (e.g.,  engine  temperature) 
comes  back.  SITE  CONTROLLER  keeps  a  record  of  activity  so  that  any  particular  operation  may 
be  replayed  on-screen  in  the  future. 
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My  experience  building  and  using  SITE  CONTROLLER  provides  valuable  lessons  for  the  future: 

•  a  substantial  percentage  of  bugs  may  be  traced  to  the  use  of  floating-point  arithmetic 
and  untyped  geometric  operations.  Reliable  systems  will  require  formal  methods  of 
error  control  or  exact  arithmetic  and  modem  approaches  to  geometric  programming. 

•  high-level  programming  languages,  such  as  Lisp,  and  the  best  available  software 
development  tools  allow  a  practical  system  to  be  built  with  only  moderate  effort. 

•  reasonably  intelligent  software  decomposition  with  a  modern  o^;‘Kt  system  provides 
enough  flexibility  for  extensions  into  unforeseen  areas  of  civil  engineering. 

•  state-of-the-art  computational  geometry  algorithms  are  barely  adequate  for  coping 
with  the  constantly  evolving  surfaces  created  by  operating  bulldozers.  I  present  one 
solution  to  the  problem  of  representing  surfaces  cut  by  bulldozers. 

•  comprehensive  site  models  are  the  key  to  making  a  useful  system  and  one  must  be 
careful  to  avoid  the  pitfalls  of  computer-aided  design  (CAD)  systems  where  raw 
geometry  is  used  to  represent  real-world  objects  that  have  important  non-geometrical 
characteristics. 

•  integrated  computer-aided  civil  engineering  systems  will  strain  object  database 
systems  to  their  limits  in  the  areas  of  performance,  version  control,  synchronization  and 
integrity. 

Civil  engineering  and  construction  are  enormous  areas  of  human  endeavor  that  have  remained 
almost  completely  unsupported  by  computers.  SITE  CONTROLLER  proves  that  a  revolution 
affecting  hundreds  of  billions  of  dollars  of  projects  might  be  achieved  by  a  small  group  of 
computer  scientists. 
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2.  Site  Controller  and  a  Typical  Project 

This  section  shows  how  SITF  CONTROLLER  is  useful  in  all  phases  of  an  earthmoving  project. 

2.1.  Describing  the  Virgin  Site 

Rebecca,  a  civil  engineer,  sits  down  at  a  computer  running  SITE  CONTROLLER.  She  is  then 
presented  with  a  collection  of  non-overlapping  windows  that  cover  the  screen.  Moving  the 
mouse  over  the  largest  window,  she  clicks  to  get  help  and  up  pops  a  menu.  This  menu  describes 
all  the  commands  accessible  in  that  window.  A  novice  would  choose  commands  from  the  menu, 
but  cm  expert  like  Rebecca  can  invoke  any  command  directly  by  holding  down  the  correct  shift 
keys  and  nKiuse  buttons. 

Rebecca  clicks  the  mouse  to  "choose  a  site  to  edit  in  this  view"  and  a  menu  pops  up  with  the 
names  of  all  the  sites  plus  an  option  to  "define  a  new  site,"  which  she  selects.  A  dialog  box  pops 
up.  After  filling  in  values  such  as  the  site  name  and  possibly  overriding  defaults  for  such 
parameters  as  contouring  interval,  Rebecca  is  ready  to  use  the  new  site. 
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Figtue  2.1  Typical  SITE  CONTROLLER  screen  showing  surveyed  points  of  known 
elevation  connected  in  a  Delaurtay  triangulation.  The  statistics  window  on  the  upper 
right  shows  detailed  data  about  one  surveyed  point. 


11 


Rebecca  already  has  an  ASCII  file  of  surface  topography  data,  either  from  photogrammetry, 
satellite  maps,  or  standard  surveying.  Another  mouse  command  turns  that  ASCII  file  into  a  list 
of  SURVEYED-POINTs  in  the  new  site's  default  SURFACE,  Surveyed  Surface^.  SITE 
CONTROLLER  now  knows  the  elevation  of  Surveyed  Surface  at,  say,  150  points.  Rebecca  has  an 
old  contour  map  of  the  area  and  wants  to  make  sure  that  there  are  no  glaring  errors  in  her  data. 
So  she  clicks  the  mouse  to  see  a  contour  map  of  the  surface,  i.e.,  the  intersections  of  the  surface 
with  regularly-spaced  planes  of  constant  elevation. 

Intersections  between  Surveyed  Surface  and  horizontal  planes  will  occur  at  arbitrary  locations, 
yet  SITE  CONTROLLER  only  knows  the  elevation  of  the  surface  at  150  discrete  locations.  Thus, 
some  kind  of  continuous  surface  must  be  interpolated  through  those  points.  SITE  CONTROLLER 
constructs  the  Delaunay  triangulation  of  the  150  surveyed  points  (see  Figure  2.1),  a  tiling  of  the 
site  with  triangles  such  that  the  vertex  of  each  triangle  is  a  point  of  known  elevation.  The 
Delaunay  triangulation  is  notable  because  it  results  in  triangles  that  are  close  to  equilateral  (as 
opposed  to  long  and  skinny).  Since  three  points  determine  a  plane,  a  natural  piecewise-planar 
faceted  surface  model  springs  immediately  from  the  triangulation.  This  kind  of  C^  surface 
would  look  somewhat  like  a  cut  diamond,  with  sharp  edges  between  facets. 

Rebecca  can  now  see  that  the  contours  do  not  match  those  in  her  existing  map,  and  that,  in 
particular,  there  is  a  500  meter  high,  2  meter  wide  tower  in  the  middle  of  the  site.  A  click  of 
the  mouse  suffices  to  superimpose  the  contour  map  in  blue  and  the  Delaunay  triangulatior'  in 
red.  Rebecca  rolls  the  mouse  around  on  the  screen  while  little  highlighting  boxes  appear 
around  the  nearest  surveyed  points.  She  positions  the  mouse  so  that  the  point  that  appears  to 
be  the  summit  of  the  peak  is  highlighted  and  clicks  to  describe  it.  In  one  of  the  auxiliary 
statistics  windows,  the  point  prints  out  its  (x,y,z)  value  and  provenance.  Rebecca  notes  that  the 
elevation  of  this  point  is  implausible  and  was  likely  due  to  a  data  entry  error;  a  flourish  of  the 
mouse  suffices  to  delete  it  from  Surveyed  Surface  and  the  E)elaunay  triangulation  is 
recalculated. 

Although  the  new  contour  map  lacks  the  extraneous  500  meter  peak,  Rebecca  is  unhappy  with 
the  appearance  of  the  contours.  PI«mar  triangular  facets  intersect  with  horizontal  planes  in 
line  segments.  Thus,  contour  lines  are  not  smooth  but  rather  piecewise-linear  with  jagged 
comers  at  triangle  boundaries.  Although  these  are  not  necessarily  less  accurate  than  smooth 
lines,  Rebecca  is  a  traditionalist  and  has  trouble  visualizing  the  site. 

Rebecca's  next  mouse  click  asks  SITE  CONTROLLER  for  smooth  contouring.  Each  triangle  is  now 
a  nine-parameter  polynomial  surface,  with  first  derivatives  continuous  across  triangle  borders. 
These  polynomial  surfaces  intersect  with  horizontal  planes  in  smooth  curves  and  Rebecca  is 
happy. 

Wishing  to  obtain  design  assistance  from  SITE  CONTROLLER  in  the  future,  Rebecca  decides  to 
add  objects  to  the  site  model.  Using  a  digitizing  tablet  to  trace  over  some  existing  blueprints, 
she  defines  roads  and  enters  data  about  their  pavement  width,  right-of-way  width,  centerline 


^  Class  names  and  otiter  fragments  of  Lisp  code  such  as  procedure  and  message  names  are  shown 
in  upper  case;  instances  of  classes  are  shown  in  italics. 
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path,  and  3D  profile.  Rebecca  traces  over  the  property  boundaries,  buried  gas  and  electric  lines, 
and  important  site  features  such  as  buildings.  SITE  CONTROLLER  represents  these  real-world 
objects  with  corresponding  objects  in  the  site  database.  Site  Controller  can  answer  questions 
about  gas  lines  because  a  gas  line  is  represented  as  a  full-fledged  object  known  to  be  a  hazard, 
not  just  as  a  few  graphical  entities  on  the  screen  with  a  human-readable  label. 

2.2.  Studying  Alternative  Surfaces 

Reber  .  has  been  hired  by  Evergreen  Development  to  figure  out  how  to  turn  some  nice  rolling 
farr  md  (Bucolic  Farm)  into  the  maximum  legal  number  of  tract  houses  (Evergreen  Estates). 
SITE  CONTROLLER  helps  Rebecca  to  break  up  Bucolic  Farm  into  lots  that  satisfy  the  zoning 
laws  of  all  relevant  political  entities.  In  particular,  SITE  CONTROLLER  is  able  to  represent 
zoning  criteria  such  as  minimum  frontage  (along  a  road),  minimum  lot  area,  how  far  back  septic 
drainage  fields  must  be  set  from  the  property  boundaries,  and  whether  portions  of  the  lot  that 
are  steeply  sloped  may  be  included  in  the  minimum  area.  Once  a  general  layout  is  complete, 
Rebecca  turns  her  attention  to  sculpting  the  terrain. 

Each  structure  must  sit  on  a  flat  "building  pad"  and  Rebecca  clicks  the  mouse  to  define  a  new 
prospective  surface  for  the  first  house  lot  (Lot  1  Surface).  Stretching  a  boundary  polygon  around 
the  area  to  be  reshaped,  she  sketches  in  new  contour  lines  and  surveyed  points.  After  the 
contours  for  the  lot  look  good,  she  instructs  SITE  CONTROLLER  to  combine  the  real  Surveyed 
Surface  with  her  prospective  Lot  I  Surface.  SITE  CONTROLLER  does  this  by  "sewing  together" 
the  two  surfaces  at  the  boundary  polygon,  preventing  any  elevation  information  from  being 
interpolated  using  data  from  the  other  side  of  the  boundary.  All  the  original  surveyed  data 
within  Lot  1  Surface's  boundary  polygon  is  ignored.  Rebecca  asks  for  a  contour  map  of  the  new 
combined  surface  and  satisfies  herself  with  the  soundness  of  the  result.  Rebecca  proceeds  in  this 
manner  to  sketch  in  surfaces  for  more  houses,  roads,  and  possibly  common  parks. 

After  Rebecca  has  finished  a  Final  Surface  coruisting  of  the  original  Surveyed  Surface 
combined  with  dozens  of  prospectives.  Evergreen  asks  her  to  estimate  the  earthmoving  cost. 

SITE  CONTROLLER  is  able  to  make  a  map  of  the  cut-and-fill  required  to  realize  Final  when 
starting  with  Surveyed,  i.e.,  each  area  that  must  be  excavated  is  highlighted  in  one  color 
while  areas  that  must  be  filled  in  are  shown  in  another.  In  addition,  SITE  CONTROLLER 
automatically  calculates  the  amount  of  earth  that  must  be  trucked  on  or  off  the  site  to  realize 
Final.  Finding  this  number  to  be  excessive,  Rebecca  raises  the  tennis  courts  to  use  up  excess  earth 
excavated  from  the  house  lots. 

However,  this  causes  Miriam,  Evergreen's  architect,  to  worry  that  the  buyers  of  Lot  37  will 
have  an  obscured  view  of  a  rtearby  lake.  Rebecca  asks  SITE  CONTROLLER  to  calculate 
intervisibility  between  the  lake  and  a  hypothetical  second  floor  window  in  Lot  37.  Learning 
that  the  view  is  in  fact  obscured,  Rebecca  raises  the  building  pad  for  Lot  37  and  Miriam  becomes 
concerned  that  tf\e  terrain  looks  unnatural  when  viewed  from  Lot  21  and  that  this  won't  appeal 
to  their  granola-eating  customer  base.  Rebecca  says  "look  at  the  contour  map — you  can  see  the 
natural  beauty  of  the  tract."  Unfortunately,  Miriam  isn't  used  to  reading  contour  maps  and  can't 
visualize  the  site.  SITE  CONTROLLER  obliges  by  generating  a  perspective  view  from  the 
viewpoint  of  a  first  floor  window  on  Lot  21  facing  Lot  37.  Miriam  is  now  satisfied. 
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Hydrology  quesdoirs  are  important  at  this  point;  i.e.,  where  are  the  ridges,  streams,  drainage 
basins,  and  pools.  Rebecca  wants  to  know  what  will  happen  if  there  is  a  “  100-year  storm"  (the 
worst  one  might  expect  in  1(X)  years  on  this  site).  She  finds  that  a  stream  cuts  right  across  one  of 
the  roads  aiui  concludes,  by  looking  at  some  of  the  ridge  lines,  that  the  stream  drains  a  large 
basin.  A  severe  storm  will  drop  a  substantial  quantity  of  water  in  that  basin  and  the  stream 
will  therefore  have  enough  power  to  wash  out  the  road.  Rebecca  adds  roadside  drainage 
ditches  and  a  culvert  (a  pipe  underneath  the  road  to  let  the  stream  flow  through).^ 

2.3.  Simulating  Construction 

Once  die  design  objectives  are  clear  and  agreed  upon,  Rebecca's  engineering  task  is  complete  and 
she  hands  off  the  design  to  Rachel,  a  local  contractor.  Rachel  uses  the  same  site  database  to 
plan  the  earthmoving  job  of  turning  Bucolic  Farm  into  Evergreen  Estates.  She  uses  SITE 
controller's  simulator  to  specify  the  paths  of  two  bulldozers  moving  over  the  site,  cutting 
Surveyed  Surface  to  the  elevation  of  Final  Surface.  The  simulator  shows  Rachel  the  bulldozers 
moving  and  the  evolution  of  the  surface  as  the  bulldozer  blades  carve.  Rachel  can  use  the  simu¬ 
lator  to  plan  construction  so  that  machines  are  utilized  efficiently  and  the  entire  job  is  done  at  a 
reasonable  cost  on  a  schedule  acceptable  to  Evergreen.^ 

2.4.  Controlling  Construction 

Evergreen  accepts  Rachel's  bid  and  work  commences.  Rachel  installs  SITE  CONTROLLER  on  a 
computer  inside  the  construction  site's  trailer  and  attaches  radio  modems  to  the  computer's 
serial  port.  Rachel  has  fitted  her  earthmovers  with  Global  Positioning  System  (GPS) 
navigation  systems,  implement  position  sensors  and,  in  some  cases,  computer  interfaces  to  the 
hydraulic  systems  that  position  the  implement. 

Because  Rachel  has  a  stationary  GPS  system  in  a  fixed  known  location  on  the  site,  the  mobile 
GPS  receivers  are  correctable  to  an  accuracy  of  a  few  millimeters.  While  the  earthmovers  are 
operating,  they  keep  SITE  CONTROLLER  apprised  of  their  position  and  status  by  sending 
packets  back  vk  the  radio  modems.  SITE  CONTROLLER  in  turn  pulls  relevant  data  from  the 
site  model  and  sends  it  back  to  the  earthmover.  For  example,  as  a  backhoe  operator's  blade  gets 
close  to  a  gas  line,  a  warning  is  automatically  sent  out  (if  the  vehicle  were  appropriately 
equipped,  data  from  the  site  model  would  restrict  the  range  of  the  backhoe's  motion  so  that  con¬ 
tact  with  the  gas  line  was  impossible).  Bulldozers  roughing  out  sections  of  the  site  are  sent 
data  about  the  design  surface  so  the  operator  may  be  informed  that  "the  blade  is  now  2  feet 
above  the  design  surface."  Motor  graders  finishing  a  layer  of  gravel  on  a  roadbed  are 
completely  controlled  by  SITE  CONTROLLER  working  with  on-board  computers — blade  height 
control  is  taken  out  of  the  operator's  hands,  enabling  the  vehicle  to  be  driven  faster  and  by  less 
skilled  operators. 


^This  portion  of  Site  Controller  needs  substantial  additiorul  development. 
^This  portion  of  Site  Controller  needs  some  redtinking  before  it  will  be  useful. 
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In  fact,  servo  control  of  implements  enables  Rachel  to  perform  precision  work  with  cheap 
machines  such  as  bulldozers  when  formerly  expensive  graders  were  required.  A  motor  grader  is 
not  35  meters  long  because  that  is  the  minimum  size  necessary  to  carry  the  blade,  but  because  a 
human  operator  is  incapable  of  working  smoothly  without  a  long  baseline.  However,  a 
computer  can  rapidly  compensate  for  a  vehicle's  roll  or  pitch  and  therefore  a  hyperstable 
platform  may  be  superfluous. 

2.5.  Litigation  (the  Way  of  All  Business) 

A  year  after  the  yuppies  move  into  Evergreen  Estates,  a  portion  of  the  main  road  crumbles. 
Evergreen  sues  Rachel,  alleging  that  she  inadequately  compacted  the  roadbed  before  paving. 
At  the  trial,  Rachel  brings  her  laptop  running  SITE  CONTROLLER  into  the  courtroom.  The  jury 
sees  that  SITE  CONTROLLER  is  able  to  reproduce  from  its  database  the  state  of  the 
Bucolic /Evergreen  project  at  any  time  during  construction.  Rachel  moves  the  playback  history 
date  up  to  the  day  when  the  roadbed  was  compacted  and  the  jury  sees  the  compactor  rolling 
back  and  forth  the  10  times  specified  by  Rebecca's  engineering  plains.  Rachel  is  off  the  hook. 

Of  course,  Rebecca  is  now  sued  for  specifying  an  inadequate  degree  of  compaction... . 

Twenty  years  after  Evergreen  Estates  are  fiiushed,  occupants  of  adjacent  Hidden  Valley 
Mansions  sue  Rebecca,  Rachel,  and  Evergreen  when  their  doctors  find  elevated  levels  of  cad¬ 
mium  among  Hidden  Valley  residents.  The  lawsuit  alleges  that  1)  the  farmer  on  Bucolic  Farms 
was  a  gadget  freak  who  tossed  hundreds  of  dead  NiCd  batteries  behind  his  bam,  2)  Rachel 
used  the  earth  containing  the  batteries  to  fill  in  the  Evergreen  Estates  baseball  diamond,  and  3) 
Rebecca's  plan  allowed  runoff  from  die  baseball  diamond  to  flow  into  Hidden  Valley.  Rachel 
uses  SITE  CONTROLLER'S  historical  database  to  show  that  earth  excavated  from  behind  said 
bam  was  used  for  fill  at  the  tennis  courts  and  further  uses  SITE  CONTROLLER'S  hydrology 
analysis  tools  to  show  that  no  runoff  from  the  baseball  diamond  or  the  tennis  courts  could  flow 
into  Hidden  Valley.  Case  dismissed. 
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3.  Why  Earthmoving? 


Construction  is  the  largest  industry  in  most  countries,  even  in  highly  developed  regions  such  as 
Europe,  North  America,  aiwl  Japan.  Indeed,  the  products  of  the  construction  industry  determine 
whether  or  not  a  country  is  considered  "developed"  or  "developing."  Third  World  countries 
may  contain  regions  of  great  productivity  or  great  beauty,  but  without  roads  to  transport  goods 
and  people  those  resources  are  useless.  By  contrast,  countries  not  blessed  by  Nature  may  make 
up  for  deficiencies  with  construction.  Portions  of  Europe  blighted  by  bad  weather  and 
uninteresting  topography  have  been  rendered  charming  by  structures  built  over  the  centuries. 
Similarly,  regardless  of  what  resources  are  inherent  in  the  land,  high  productivity  can  be 
achieved  with  roads,  power  plants,  high-speed  rail  links,  and  modem  factories. 

Although  construction  in  the  United  States  is  not  typical  of  the  rest  of  the  world,  it  is  well 
characterized.  New  construction  in  the  U.S.  was  worth  $446  billion  in  1990,  or  8%  of  GNP. 
Adding  the  value  of  alterations,  maintenance,  and  "unsjjecified"  work,  the  total  is  nearer  $700 
billion,  or  12%  of  GNP  [U.S.  Department  of  Commerce  1991;  Bureau  of  the  Census  1987].  U.S. 
construction  directly  employs  over  5  million  people,  or  about  5%  of  the  labor  force — without 
including  people  employed  by  material  suppliers  and  equipment  manufacturers  [U.S. 
Department  of  Labor  1989).  This  fraction  of  the  labor  force  has  been  more  or  less  constant  since 
1920,  when  statistics  were  first  calculated. 

Since  the  mid-1960's,  botfi  industry  productivity  and  size  relative  to  the  economy  have  been  de¬ 
clining.  The  value  of  new  construction  fell  from  11.9%  of  GNP  in  1966  to  8.1%  in  1990. 
Productivity  has  sinvilarly  declined  by  at  least  33%  over  the  same  period  [Demsetz  1989].  A 
variety  of  factors  have  contributed  to  the  decline  in  importance  and  effectiveness  of  construction 
in  the  U.S.: 

•  Many  of  the  things  worth  building  have  been  built.  The  first  bridge  over  a  river  is 
built  in  the  easiest  location  and  has  the  most  value  to  people  formerly  forced  to  take 
ferries.  Subsequent  bridges  provide  some  convenience  and  congestion  relief,  but  on  aver¬ 
age  cost  more  and  are  worth  less.  Similarly,  most  of  the  best  sources  of  hydroelectric 
power  in  the  U.S.  have  been  tapp>ed. 

•  People  purchase  less  of  goods  and  services  that  represent  poor  value.  When  car  radios 
and  mobile  phones  were  expensive  and  highway  construction  cheap,  people  spent  tax 
dollars  on  highways.  Today,  people  may  think  it  wiser  to  buy  a  Sony  car  stereo  and 
cellular  phone  that  will  make  traffic  jams  endurable  than  to  pay  an  inefficient  gov- 
emment/industry  coalition  to  build  a  new  highway. 

•  As  an  ever-greater  portion  of  the  nation  is  covered  with  buildings,  roads,  and  facto¬ 
ries,  a  growing  percentage  of  construction  is  renovation  and  redevelopment,  which  may 
be  more  labor-intensive  than  new  construction. 

•  Techniques  have  stagnated,  yet  wages  rise.  Since  productivity  is  the  amount  of  output 
per  labor  dollar,  people  who  produce  no  more  per  hour  but  get  paid  more  per  hour  will 
be  called  'less  productive."  U.S.  firms  invest  only  about  0.4%  of  revenues  in  R&D  and 
thus  innovations  must  be  imported  from  Europe  and  Japan,  where  1%  of  revenues  are  so 
invested. 
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Construction  in  the  rest  of  the  world  differs  in  several  consistent  respects.  In  the  Third  World,  a 
greater  proportion  of  GNP  is  spent  on  construction  and  much  of  that  is  spent  on  traditional 
earthmoving  projects.  Because  Third  World  construction  still  uses  a  lot  of  manual  labor, 
productivity  is  rising  as  n>ore  machines  are  introduced.  Europ)e  and  Japan  differ  from  the  U.S. 
primarily  in  that  their  construction  firms  invest  in  R&D  and  are  constantly  developing  new 
techniques  that  increase  productivity. 

When  tackling  the  problem  of  improving  construction  productivity,  earthmoving  is  a  natural 
place  to  look  for  automation  opportunities.  All  kinds  of  earthmoving  jobs  are  essentially 
sinular,  whether  hazardous  waste  is  being  excavated  or  a  roadbed  being  laid.  This  contrasts 
with  building  construction  where  techruques  used  to  build  a  steel-and-glass  office  tower  may  be 
of  no  use  when  constructing  a  brick  apartment  house.  Earthmoving  represents  a  sizable 
percentage  of  the  entire  construction  industry,  from  about  10%  in  the  U.S.  to  perhaps  30%  in  the 
Third  World.  Furthermore,  all  the  building  blocks  that  make  computer-aided  earthmoving 
possible  have  become  available  recently.  These  include  the  following: 

•  accurate  rugged  inexpensive  location  systems,  notably  the  Global  Positioning  System 
of  satellites 

•  computational  geometry  algorithms  capable  of  efficiently  handling  problems  as  the 
amount  of  data  gets  large  enough  to  accurately  model  real  sites 

•  object  data  management  systems  that  are  orders  of  magrutude  faster  at  handling  the 
kind  of  data  that  arise  in  civil  engineering  than  are  traditional  relational  databases 

•  inexpensive  powerful  computers. 

Before  diving  into  the  specifics  of  applying  new  technologies,  let's  step  back  for  a  minute  and 
consider  which  earthmoving  problems  are  considered  inadequately  addressed  by  current  tech¬ 
nology. 

Hazardous  waste  site  remediation  is  one  of  the  few  civil  engineering  problems  that  has 
attracted  the  attention  of  the  American  public.  Respondents  to  a  Louis  Harris  poll  rated  a 
clean  environment  more  important  than  a  satisfactory  sex  life  [Stutz  1990].'^  In  the  United 
States  alone,  there  are  over  1,200  Superfund  sites  and  cost  estimates  for  remediating  those  sites 
range  from  500  to  1,200  billion  dollars.  More  sites  are  added  to  the  Superfund  list  each  year  and 
yet,  since  the  program's  inception  in  1980,  only  33  sites  have  been  fully  cleaned  up  at  a  cost  of 
over  $10  billion.  Superfund  sites  represent  only  a  fraction  of  the  contaminated  earth  in  the  U.S. 
and  thus  it  should  be  clear  that  even  a  rich  society  such  as  the  U.S.  cannot  afford  to  clean  up  all 
of  its  hazardous  waste  with  existing  techruques. 

Cleaning  up  a  hazardous  waste  site  consists  essentially  of  surveying  the  site,  developing  a  plan 
for  excavation,  excavating  the  contaminated  earth  and  moving  it  to  a  disposal  or  incineration 
site,  and  finally,  somehow  restoring  the  original  site  to  a  usable  condition.  Many  of  the  steps 
involved  in  cleanup  are  the  same  as  for  a  traditional  earthmoving  job,  except  that  record¬ 


'll  can  remember  when  the  air  was  clean  and  sex  was  dirty.  —  George  Bums 


keeping  requirements  are  more  stringent  and  workers  must  be  protected  from  hazardous 
materials. 

Another  glaring  problem,  albeit  one  that  overlaps  somewhat  with  hazardous  waste 
remediation,  is  that  of  equipment  utilization.  Ask  most  people  to  visualize  a  construction  site 
and  their  first  response  is  "I  see  a  bunch  of  enormous  yellow  machines  sitting  idle  while  a  few 
workers  stand  around  either  making  measurements  or  staring  at  blueprints."  Given  that  each 
yellow  machine  can  cost  nearly  one  nullion  dollars  and  is  only  used  about  one  third  of  the  time 
on  a  typical  construction  job,  it  is  natural  to  think  that  if  one  could  keep  the  equipment  running 
constantly  the  job  could  be  completed  faster  and  cheaper.  Machine  operators  often  must  wait  for 
hours  while  surveyors  study  blueprints,  make  measurements  and  finally  drive  stakes  into  the 
ground  to  show  the  operators  where  and  how  much  to  cut.  The  key  to  moving  earth  produc¬ 
tively  is  to  use  location  and  control  systems  that  free  equipment  operators  from  reliance  on  sur¬ 
veyors  and  blueprints.  This  is  well  understood  by  mine  operators,  who  strive  for,  and  regularly 
achieve,  over  90%  equipment  utilization,  24  hours  a  day. 

That  equipment  productivity  is  the  most  important  goal  is  thrown  into  sharp  focus  by  Third 
World  projects.  Labor  is  nearly  free  when  compared  with  a  $500,000  bulldozer  or  $700,000 
truck,  so  the  cost  of  the  project  is  entirely  determined  by  the  number  of  days  on  which  machines 
are  rented  and  the  cost  of  maintaining  those  machines. 

One  of  the  biggest  inadequately  solved  problems  is  one  that  we  have  created  ourselves:  com¬ 
pliance  with  legal  and  regulatory  demands.  If  one  wanted  to  start  an  automobile  company  in 
tum-of-the-caitury  America,  all  one  needed  to  do  was  design  a  saleable  product.  Today,  one 
would  first  have  to  hire  dozens  of  lawyers  to  work  for  a  year  just  to  read  all  the  relevant  laws 
cuid  regulations.  Cars  are  safer  and  cleaner  today,  but  19th  century  business  practices  no  longer 
suffice.  Litigation  and  regulation  have  similarly  complicated  earthmoving,  yet  business  prac¬ 
tices  have  not  adapted  nearly  as  well  to  the  new  environment.  One  result  is  that  compliance 
with  regulations  is  enormously  burdensome  and  therefore  expensive.  Another  is  that  nearly  ev¬ 
ery  large  construction  job  gives  birth  to  at  least  one  lawsuit. 

Inaccurate  estimates  often  give  rise  to  lawsuits.  If  the  estimate  is  too  low,  the  contractor  will 
lose  money  uidess  he  somehow  manages  to  foist  the  blame  for  the  cost  overrun  on  someone  else. 

In  fact,  some  contractors  underbid  jobs  on  purpose  with  the  expectation  that  a  fair  price  will  be 
recovered  in  a  subsequent  lawsuit  over  undisclosed  or  unforeseen  conditions  on  the  site.  This 
practice  dates  back  at  least  to  the  mid-1800's  and  the  enlargement  of  the  Erie  Canal:  "It  was  a 
notorious  fact  that  contractors  did  not  scan  very  closely  the  character  of  the  work  they  were 
bidding  for,  the  main  thing  being  to  get  the  work,  which  according  to  law,  must  go  to  the  lowest 
bidder.  Political,  and  possibly  corrupt  influence,  was  firmly  relied  upon  to  get  'relief'  from  the 
Canal  Board  at  Albany."  (Ainsworth  1901]  Computer-aided  estimation  and  simulation  avail¬ 
able  to  both  the  client  and  contractor  might  make  for  a  better  understanding  of  the  task  by  both 
parties,  more  realistic  estimates,  and  hence  less  litigation. 

Feeding  the  government  paperwork  monster  is  a  task  to  which  computers  have  proved  equal  in 
other  Belds.  However,  without  complete  information  about  a  construction  project  from  start  to 


19 


finish,  such  as  where  each  bucketful  of  contaminated  earth  came  from  and  is  going  to,  it  is  im¬ 
possible  for  computer  systems  to  be  of  much  use  in  satisfying  regulatory  filing  requirements. 


To  summarize,  I  chose  to  work  in  computer-aided  earthmoving  because  it  is  an  area  where  a 
small  amount  of  engineering  effort  can  yield  enormous  dividends  due  to  the  primitive  nature  of 
current  techniques  and  the  new  challenges  that  face  society. 


4.  Pioneering  Civii  Engineering  Software 

One  machine  can  do  the  work  of  fifty  ordinary  men.  No  machine  can  do  the  work  of  one 
extraordinary  man.  —  Elbert  Hubbard 

Civil  engineers  have  been  extremely  poorly  served  compared  with  other  kinds  of  engineers  by 
the  computer  software  community.  Factors  contributing  to  the  dearth  of  useful  software  include 
the  following; 

•  Computers  can  do  almost  nothing  to  help  construction  without  knowing  where  ma¬ 
chines  and  materials  are  physically  located,  yet  accurate,  inexpensive  location  systems 
are  barely  available  even  today. 

•  Civil  engineering  is  unstructured  and  requires  much  more  flexible  databases  and  soft¬ 
ware  than  other  disciplines.  On  a  construction  site,  nothing  can  be  predic  I:  in  a  fac¬ 
tory,  everything  can  be  controlled. 

•  IDesign  civil  engineers  get  paid  by  the  hour  and  are  therefore  not  necessarily  hungry 
for  productivity  aids. 

•  Design  civil  engineers  have  little  money  and  are  not  used  to  making  capital  invest¬ 
ments,  yet  civil  engineering  problems  require  massive  computational  resources  that 
were  prohibitively  expensive  until  recently. 

•  Efficient  computational  geometry  algorithms  were  not  available  until  the  1980's  so 
that,  even  given  massive  computers,  civii  engineering  problems  would  have  been 
intractable  with  the  algorithms  of  the  day 

•  Civil  engineers  generally  lack  formal  computer  science  backgrounds  and  are  unable  to 
write  complex  tools  themselves.  By  contrast,  the  most  sophisticated  CAE  (computer- 
aided  engineering)  programs  to  date  were  written  by  electrical  engineers  to  solve 
integrated-circuit  design  problems. 

Characterizing  the  smallest  civil  engineering  site  to  a  useful  level  of  detail  requires  at  least 
several  megabytes  of  memory.  Manipulating  and  displaying  that  data  in  real  time  requires  a 
computer  capable  of  at  least  10  MIPS.  Until  the  late  1980's,  the  smallest  computers  capable  of 
being  useful  assistants  to  the  civil  engineer  cost  over  $100,000.  Thus,  building  design  software 
for  civil  engineers  would  have  been  pointless  because,  even  if  one  had  given  away  software  free, 
few  users  would  have  beai  able  to  afford  the  requisite  hardware.  Construction  firms  accus¬ 
tomed  to  investing  heavily  in  capital  equipment  would  not  have  found  such  software  useful  be¬ 
cause  location  systems  were  too  expensive  and  inaccurate. 

Even  in  the  1990's,  building  a  comprehensive  solution  to  the  problems  of  civil  engineering 
design,  earthmoving,  and  site  maintenance  will  require  the  most  advanced  tools,  die  best 
programmers,  the  latest,  most  efficient  algorithms.  Such  a  system  would  likely  be  larger  and 
more  complex  than  the  most  comprehensive  electrical  and  mechanical  CAE  systems. 

Undaunted  by  these  formidable  challenges,  a  group  at  MIT  in  the  1960's  developed  the 
Integrated  Civil  Engineering  System  (ICES),  the  progenitor  of  all  computer-aided  civil  engi¬ 
neering  programs  [Roos  1967].  ICES  was  a  programming  environment  for  solving  civil 
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engineering  problems.  Starting  from  the  primitive  foundation  of  FORTRAN  running  on  the  IBM 
System/360,  ICES  provided  many  of  the  features  of  modem  programming  environments. 

A  cornerstone  of  ICES  is  metalinguistic  abstraction  (see  §5.1.4),  i.e.,  defining  "problem-oriented 
languages."  The  most  famous  ICES  languages  are  COGO  (Coordinate  GeOmetry),  carried  over 
from  a  1960  effort  on  the  IBM  1620,  and  STRUDL,  a  system  for  structural  analysis.  All  of  the 
problem-oriented  languages  were  implemented  in  ICETRAN,  an  extension  of  FORTRAN  that 
was  compiled  into  FORTRAN  by  a  preprocessor. 

Dynamic  linking,  compound  data  structures,  dynamic  memory  allocation,  and  pointers  for  link¬ 
ing  data  structures  made  ICETRAN  programmers  substantially  more  productive  than  their 
counterparts  using  FORTRAN  and  standard  hx)ls. 

COGO  was  widely  adopted  for  processing  survey  data  by  civil  engineers  working  with  comput¬ 
ers.  Even  today,  dozens  of  COGO  implementations  are  available  for  persor\al  computers.  A 
more  important  legacy  of  ICES  was  the  blossoming  of  software  development  groups  inside  large 
civil  engineering  firms  during  the  1970's.  In-house  programs  were  developed  to  facilitate  land 
and  building  design,  generate  three-dimensiortal  graphics,  and  perform  all  kinds  of  analysis. 

Digital  Equipment's  VAX  minicomputer  was  the  first  machine  capable  of  supporting  draftsmen 
and  engirteers  interactively  at  a  reasonable  price.  By  the  early  1980's,  CAD  firms  such  as 
Intergraph  were  selling  products  for  mapping  and  earthworks  design  to  anyone  willing  to  invest 
$1  million.  Unfortunately,  such  systems  seldom  proved  economical.  Clients  were  unwilling  to 
pay  an  hourly  supplement  for  a  designer  using  a  computer,  the  management-of-complexity 
problems  did  not  justify  a  $1  million  system,  and  the  available  programs  were  simply  not  much 
more  powerful  than  manual  techniques. 

The  1990's  should  be  the  decade  in  which  civil  engineers  are  finally  able  to  get  meaningful 
assistance  from  computers,  and  SITE  CONTROLLER  is  an  example  of  the  kind  of  software  that  I 
envision  becoming  commonplace  by  the  end  of  the  decade. 
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5.  Selecting  Software  Development  Tools 


In  building  SITE  CONTROLLER,  I  hoped  to  substantially  improve  on  the  state  of  the  art  in 
computer-aided  earthmoving  with  only  my  own  efforts  over  a  period  of  a  few  nfK)nths.  It  was 
therefore  important  to  choose  a  productive  software  development  environment,  consisting  of  a 
programming  language  and  tools  such  as  compilers,  linkers,  and  debuggers. 

5.1.  Language  Requirements 

I  settled  upon  the  following  language  requirements; 

•  automatic  storage  management 

•  modem  object  system  with  method  combination  and  a  class  hierarchy  that  can  be 
extended  at  run-time 

•  ability  to  write  higher-order  procedures 

•  ability  to  perform  metalinguistic  abstraction 

•  powerful  arithmetic  incorporating  both  a  formal  model  of  absolutely  machine-inde¬ 
pendent  generic  arithmetic  and  support  for  exact  arithmetic 

•  compact  (few  lines  of  code) 

The  next  sections  describe  in  detail  each  requirement. 

5.1.1.  Automatic  Storage  Management 

Computer-aided  design  and  engineering  programs  all  have  the  characteristic  that  objects  of  un¬ 
predictable  size  are  frequently  created  in  response  to  user  actions.  With  an  integrated<ircuit 
design  program,  the  user  might  add  a  transistor  or  connection.  With  a  mechanical  design  pro¬ 
gram,  the  user  might  add  a  lightening  hole  to  a  suspension  arm.  With  a  site  modelling  pro¬ 
gram,  the  user  might  add  a  simple  blueprint  aimotation  or  something  as  complex  as  a  scanned 
photograph.  In  all  of  these  cases,  the  object  must  be  stored  until  it  is  explicitly  deleted  by  the 
user.  It  is  possible  for  the  programmer  to  manage  the  storage  of  these  objects  explicitly,  allocat¬ 
ing  storage  from  a  heap  when  the  user  creates  an  object  and  calling  a  deallocation  procedure 
when  the  user  deletes  the  object. 

Much  more  difficult  is  the  management  of  objects  created  as  intermediate  steps  in  geometric 
computation.  For  example,  a  database  may  store  certain  data  in  a  singly-linked  list  for  storage 
efficiency.  However,  it  may  be  impossible  to  perform  a  certain  kind  -^f  analysis  efficiently 
without  a  doubly-linked  list.  In  response  to  a  user  query,  data  is  extracted  from  a  portion  of  the 
database,  stored  in  a  doubly-linked  list  and  manipulated  by  numerous  procedures  to  obtain  a  re¬ 
sult.  A  typical  bug  arises  when  a  procedure  deallocates  the  temporary  data  structure,  but  an¬ 
other  procedure,  possibly  programmed  by  a  different  individual,  still  holds  a  pointer  to  that 
data  structure  and  doesn't  realize  that  the  pointer  is  no  longer  valid.  Meanwhile,  the  heap 
manager  has  allocated  the  storage  space  to  another  part  of  the  program  and  two  procedures  are 
hammering  away  at  the  same  memory  locations,  each  unaware  that  the  other  has  overwritten 
its  data. 


23 


It  is  theoretically  possible  for  programs  to  track  every  object  they  use  and  explicitly  identify 
objects  that  are  no  longer  needed.  In  practice,  especially  in  the  CAE  world  where  complex  sys¬ 
tems  and  multiple  cooperating  programmers  are  the  rule,  programmers  make  mistakes  and  stor¬ 
age  allocation  bugs  bedevil  the  system.  Typical  large  CAE  programs  are  hobbled  by  ad  hoc 
storage  management  schemes  that  are  both  slow  and  imperfect.  Users  come  to  accept  the  fact 
that  the  program  will  crash  occasionally  and  guard  against  it  by  storing  multiple  versions  of 
the  database  on  disk. 

Automatic  storage  marugement  works  by  giving  the  programmer  the  illusion  that  the  comput¬ 
er's  memory  is  infinite.  There  are  procedures  that  allocate  storage,  but  no  deallocation  proce¬ 
dures.  Every  so  often  the  garbage  collector  looks  through  the  memory,  finds  objects  that  can 
provably  no  longer  be  accessed,  and  makes  the  memory  consumed  by  those  objects  available  for 
reuse.  For  example,  a  temporary  data  structure  that  was  available  only  as  a  local  variable  of  a 
procedure  that  has  terminated  would  be  g.*rbage  collected  because  there  is  no  pointer  anywhere 
in  the  memory  that  refers  to  it.  In  theory,  garbage  collection  slows  down  execution  because  the 
garbage  collector  is  dumb,  i.e.,  it  knows  and  assumes  nothing  about  the  data.  A  programmer 
should  be  able  to  do  a  better  job  because  he  knows  which  variables  store  what — this  is  in  fact 
the  case  for  very  simple  programs.  However,  garbage  collectors  not  only  eliminate  storage 
allocation  bugs,  but  also  make  programs  run  faster  for  anything  as  complex  as  even  the  simplest 
CAE  systems.  Some  programmers  will  argue  the  point,  but  it  is  important  to  keep  in  mind  that 
compilers  were  considered  inefficient  by  many  programmers  for  decades — despite  evidence  that 
they  did  a  better  job  of  register  allocation  and  translation  into  machine  language  than  humans 
once  a  certain  complexity  was  exceeded. 

No  comprehensive  civil  engineering  CAE  system  has  a  chance  of  working  reliably  and  satisfy¬ 
ing  regulatory  and  legal  requirements  if  its  programmers  caimot  take  advantage  of  automatic 
storage  management.  However,  standard  implementations  of  most  older  computer  languages 
preclude  garbage  collection.  The  simple  fact  of  permitting  pointers  to  be  stored  as  ordinary 
integers  prevents  a  garbage  collector  from  knowing  whether  or  not  something  is  unused.  (If 
there  is  a  variable  somewhere  with  the  value  10247,  does  that  mean  that  the  object  stored  at 
memory  location  10247  is  not  garbage,  or  that  a  loop  just  finished  executing  10247  times?). 
Standard  implementations  of  popular  languages  such  as  C,  C++,  and  PASCAL  all  have  this 
shortcoming.  Modifications  to  the  runtime  system  and  the  way  in  which  data  is  stored  can 
allow  older  languages  to  be  garbage-collected  with  certain  limitations  (see  [Weiser  1989],  [Yip 
1991],  [Dedefs  1990]).  Modem  languages  such  as  Lisp,  Smalltalk,  and  MODULA-3  incorporate 
automatic  storage  management  as  a  standard  feature. 

5.1.2.  Object-Oriented  Programming 

A  modem  object-oriented  programming  system  allows  efficient  organization  of  software  by 
automatically  combining  pieces  of  code  from  different  locations.  A  description  of  all  the  objects 
in  a  system  may  be  factored  into  classes  and  any  given  object  is  an  instance  of  a  particular  class. 
A  typical  object  will  be  an  instance  of  a  class  that  inherits  from  many  superclasses. 
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Figure  5.1  Sample  class  hierarchy  for  the  representation  of  a  Caterpillar  D9 
Bulldozer. 

For  example,  a  bulldozer  might  be  represented  as  an  instance  of  the  class  D9-BULLDOZER, 
which  is  a  subclass  of  CATERPILLAR-BULLEXDZER,  which  is  itself  a  subclass  of 
BULLDOZER. 


Functions  that  are  needed  by  several  different  kinds  of  objects  need  only  be  written,  debugged, 
and  modified  in  one  place.  For  example,  consider  the  object  Bulldozer  WIFB,  an  instance  of  the 
class  D9-BULLDOZER.  The  message  TOP-SPEED  would  be  handled  by  a  function  associated 
with  the  class  VEHICLE,  using  data  supplied  by  the  class  D9-BULLDOZER. 

Method  combination  is  a  feature  that  allows  small  pieces  of  code  associated  with  different 
classes  to  be  combined  to  form  a  single  method  of  responding  to  a  message.  Sending  a  DRAW- 
YOURSELF  message  to  the  object  Bulldozer  WIFB  might  result  in  a  piece  of  code  associated 
with  the  class  DISPLAYABLE-ACTOR-MIXIN  clearing  a  region  of  the  viewing  window,  a 
piece  of  code  associated  with  the  class  CATERPILLAR-BULLDOZER  drawing  an  icon  in  that 
newly-cleared  space,  then  a  piece  of  code  associated  with  the  class  D9-BULLIX)ZER  drawing 
a  "D9"  symbol  in  the  middle  of  the  icon.  Code  for  clearing  the  appropriate  portion  of  the  screen 
is  shared  among  all  displayable  actors;  code  for  drawing  the  Caterpillar  bulldozer  icon  is 
shared  among  all  different  types  of  Caterpillar  bulldozers. 

Multiple  superclasses  are  illustrated  in  Figure  5.1  where  BULLDOZER  and  HAS-DIESEL- 
ENGINE-MIXIN  are  both  superclasses  of  CATERPILLAR-BULLDOZER.  Description 
factorization  can  be  much  more  complete  when  each  independent  behavior  is  represented  in  a 
separate  class.  Thus  the  essential  elements  of  a  bulldozer  are  captured  in  the  BULLDOZER 
class  but  the  complexities  of  diesel  engines  are  separated  in  the  HAS-DIESEL-ENGINE- 
MIXIN  class  and  that  class  can  be  mixed  into  descriptions  of  trucks,  backhoes,  graders,  and  any¬ 
thing  else  that  uses  a  diesel  engine. 

An  aspect  of  object-oriented  programming  that  is  essential  to  CAE  systems  is  the  ability  to  ex¬ 
tend  the  class  hierarchy  at  runtime.  All  CAE  systems  share  the  property  that  a  rich  collection 
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of  building  blocks  is  provided  to  the  user  and  that  this  set  provided  falls  just  short  of  being 
comprehensive  enough.  Implementing  these  building  blocks  using  a  factored  description  in  a 
class  hierarchy  is  straightforward.  However,  if  this  class  hierarchy  cannot  be  extended  at 
runhme,  the  program  and  the  user  are  forced  into  contortions.  For  example,  an  architectural 
design  system  that  provided  750  possible  kinds  of  windows  would  surely  leave  out  the  one 
window  that  Joe  User  wanted — joe  wants  one  with  four  panes  in  the  top  sash  and  eight  in  the 
bottom.  A  few  mouse  motions  and  commands  from  Joe  should  be  enough  to  describe  the  new 
window  and  a  few  hundred  bytes  of  code  should  suffice  to  define  a  class  in  the  window  class 
hierarchy.  However,  if  this  hierarchy  cannot  be  extended  at  runtime,  there  is  no  obvious  way 
that  Joe's  custom  window  can  be  handled  by  the  same  code  that  handles  the  existing  750  types. 

A  final  desirable  feature  of  an  object  system  is  suppiort  for  operations  that  depend  on  the  class  of 
two  arguments,  which  are  rather  common.  In  a  geometry  system,  the  generic  operation 
INTERSECT  would  do  very  different  things  if  applied  to  a  point  and  a  line  or  if  applied  to  a 
plane  and  a  sphere.  Different  code  would  be  required  and  results  of  different  types  would  be 
returned.  An  object-oriented  programming  system  that  supports  dispatching  on  the  classes  of 
multiple  arguments  can  be  very  useful  for  organizing  software  to  handle  operations  such  as 
INTERSECT. 

Smalltalk  (see  [Goldberg  and  Robson  1983])  and  the  Common  Lisp  Object  System  (CLOS,  see 
[Gabriel  1991;  Steele  1990;  Keene  1989))  are  the  only  two  object-oriented  programming 
environments  that  contain  the  preceding  basic  features  essential  for  CAE  programs. 

5.1.3.  Higher-Order  Procedures 

A  procedure  is  a  means  of  abstraction.  Many  parts  of  a  CAE  programs  need  to  clear  a  window 
before  displaying  some  information.  Clearing  a  window  is  a  compound  operation  that  has  many 
subparts,  some  of  which  will  depend  intimately  upon  the  window  system  and/or  computer  being 
used.  Rather  than  distribute  copies  of  code  to  perform  this  compound  operation  throughout  the 
CAE  program,  a  programmer  would  typically  define  a  CLEAR- WINEXDW  procedure.  Defining 
procedures  reduces  code  size,  increases  perspicuity,  and  facilitates  maintenance  and  porting. 

Procedures  that  manipulate  procedures  are  called  higher-order  procedures  [Abelson  and 
Sussman  1985]  and  such  procedures  vastly  increase  the  expressive  power  of  a  computer  language. 
Suppose  that  you  want  to  print  out  the  value  stored  at  every  leaf  in  a  tree  data  structure  and 
also  accumulate  the  sum.  Without  higher-order  procedures,  you'd  have  to  write  a  procedure, 
PRINT-LEAVES,  that  included  p)ossibly  complex  tree-walking  code  as  well  as  die  simple  value 
extraction,  summing  and  printing  code.  Worse  yet,  if  you  ever  decide  to  change  the  way  trees 
are  represented,  you'll  have  to  change  PRINT-LEAVES. 

Suppose  that  you  create  a  higher-order  procedure,  APPLY-TO-LEAVES,  that  takes  a  tree,  Tl, 
and  a  procedure,  LEAF-PROC,  as  arguments.  APPLY-TO-LEAVES  walks  through  the  tree  and 
calls  the  procedure  LEAF-PROC  on  every  leaf.  Any  part  of  the  CAE  program  that  needs  to 
perform  computation  on  die  leaves  of  a  tree  can  use  APPLY-TO-LEAVES  and  if  the  tree  data 
structure  is  modified,  only  this  one  procedure  need  be  updated. 
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Higher-order  procedures  are  mostly  useful  in  languages,  such  as  Lisp,  where  procedures  are 
first<'as8  objects  arxi  can  be  created  at  run-time.  For  example,  in  the  case  of  using  APPLY -TO- 
LEA  .  ES  to  print  leaf  values,  you  won't  know  where  the  user  wants  the  information  printed  un¬ 
til  runtime  and  therefore  it  is  convenient  to  wait  until  the  user  invokes  a  command  before  creat¬ 
ing  a  LEAF-PRCXZ  that  incorporates  the  window  or  other  destination  specified  by  the  user. 

5.1.4.  Metalinguistic  Abstraction 

No  general-purpose  computer  language  is  adequate  to  solve  the  most  complex  problems.  To  ex¬ 
press  ideas  effectively  and  compactly,  it  is  frequently  necessary  to  develop  new  formal  lan¬ 
guages.  This  process  is  called  metalinguistic  abstraction  [Abelson  and  Sussman  1985]. 

Describing  municipal  zoning  laws  is  a  typical  problem  that  can  be  easily  solved  with  metalin¬ 
guistic  abstraction.  A  simple  formal  declarative  language  would  suffice  to  permit  the  expres¬ 
sion  of  concepts  such  <is  "septic  tanks  must  be  set  back  at  least  50  meters  from  any  property 
bourvlaiy ." 

Developing  new  languages  has  traditionally  been  considered  difficult  because  people  become 
preoccupied  with  irrelevant  matters  such  as  syntax  and  parsing.  Lisp  programmers  have  taken 
advantage  of  this  method  of  abstraction  for  decades.  It  is  easy  to  develop  a  language  embedded 
in  Lisp  for  the  following  reasons: 

•  Lisp  has  uniform  syntax:  parentheses  surrounded  function  names  and  arguments.  This 
syntax  can  be  used  for  any  embedded  language  and  the  resulting  language  can  be  parsed 
by  the  same  system  procedures  that  read  Lisp  code. 

•  Lisp  was  designed  to  be  introspective,  i.e..  Lisp  programs  are  able  to  manipulate  and 
construct  other  Lisp  programs.  All  the  native  Lisp  functions  that  are  used  to  pull  apart 
Lisp  code  can  be  used  to  analyze  the  embedded  language. 

•  Lisp,  althou^  normally  compiled,  contains  as  part  of  its  standard  the  EVAL  proce¬ 
dure.  EVAL  evaluates  Lisp  code  at  nmtime,  functioning  as  an  interpreter.  Thus,  embed¬ 
ded  languages  can  be  translated  into  Lisp  code  at  runtime  and  the  resulting  Lisp  evalu¬ 
ated  directly. 

Civil  engineering  encompasses  such  a  diversity  of  problems  that  metalinguistic  abstraction  be¬ 
comes  an  essential  tool. 

5.1.5.  Arithmetic 

Most  people  think  of  computers  as  exceptionally  talented  at  arithmetic.  Unfortunately,  most 
computer  languages  are  so  primitive  in  this  regard  as  to  be  almost  useless  for  many  of  the  sur¬ 
face  modelling  and  other  problems  in  computer-aided  civil  engineering.  For  example,  a  C  pro¬ 
gram  may  produce  different  results  when  executed  on  computers  with  different  word  sizes  or 
that  store  the  bytes  in  multibyte  integers  in  a  different  order.  Neither  execution  will  ternunate 
in  an  error,  and  the  user  will  end  up  with  two  different  answers,  both  probably  wrong.  A 
FORTRAN  program  developed  on  a  32-bit  machine  and  that  has  worked  flawlessly  for  two 
years  may  break  in  an  incomprehensible  way  when  rim  on  a  64-bit  machine. 
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Floating-point  arithmetic  has  been  fraught  with  perils  since  the  dawn  of  electronic  computa¬ 
tion.  Consider  the  following  equations; 

2x-x  +  x,  x  +  y  =  y  +  x,  lx  =  x,  {x  + y)  + z  =  x  +  (y  + z)- 

What  do  they  have  in  common?  They  are  all  false  in  some  implementations  of  floating-point 
arithmetic.  Yet  cm  optimizing  compiler  may  reorder  operations  based  on  those  equations  in 
order  to  make  a  program  run  faster.  Recent  standards  [IEEE  1987]  for  floating-point  arithmetic 
eliminate  many  pitfalls,  both  in  day-to-day  arithmetic  and  when  mox'ing  a  program  to  new 
computer  systems.  However,  the  IEEE  standards  do  not  specify  how  certain  features  are  to  be 
made  available  in  programming  languages.  Thus  a  program  that  initializes  a  variable  to 
"IEEE  infinity"  might  not  run  on  another  computer,  even  if  both  claim  to  support  the  same 
language  and  IEEE  floating-point  arithmetic. 

As  inaccurate  as  they  are,  it  is  disturbing  to  discover  that  floating-point  numbers  are  enshrined 
in  virtually  every  numerical  algorithm  implementation  available,  a  tribute  to  the  high  speed 
of  floating-point  hardware  and  the  inflexibility  of  most  computer  languages.  Algorithms  are 
usually  generic  ideas  that  are  independent  of  the  type  of  numbers  used.  For  example,  a  program 
that  constructs  a  Delaunay  triangulation  of  a  set  of  points  shouldn't  care  whether  the  points  are 
specified  by  integers,  floating-point  numbers,  extended  precision  floating-point  numbers, 
rational  numbers,  etc.  Yet  almost  all  computer  languages  require  every  procedure  that  ma¬ 
nipulates  numbers  with  the  language  primitives  to  declare  the  type  of  number  expected.  Code 
is  tfius  more  difficult  to  reuse  and  becomes  cluttered  with  irrelevant  details. 

Computational  geometry  algorithms  published  in  academic  journals  are  only  guaranteed  to 
work  if  arithmetic  is  precise.  Unfortunately,  few  computer  languages  provide  exact  arithmetic 
except  for  integers  within  a  limited  range.  Small  errors  in  floating-point  arithmetic  can  pro¬ 
duce  topological  errors  in  data  structures  and  geometric  reasorting.  For  example,  a  point  might 
be  thought  outside  of  a  triangle  when  it  is  actually  enclosed  within  the  triangle.  Tradition¬ 
ally,  the  programmer  will  add  "epsilon"  tolerances  in  every  part  of  the  program  that  fails 
during  testing.  A  procedure  that  determines  if  a  point  is  on  a  line  by  calculating  an  iimer 
product  and  checking  to  see  if  the  result  is  zero  will  instead  check  to  see  if  the  result  is  within  a 
small,  arbitrarily-determined  "epsilon"  of  z^ro.  Unforhmately,  this  kind  of  ad  hoc  kludging 
inevitably  leads  to  the  program  failing  when  a  user  hands  it  an  unanticipated  case. 

It  is  possible  to  represent  and  compute  with  integers  of  arbitrary  size.  Then,  overflow  results  in 
longer  execution  time,  not  an  erroneous  result  or  aborted  execution.  With  the  provision  of  ratio¬ 
nal  numbers,  i.e.,  quotients  of  arbitrarily  large  integers,  it  is  possible  to  perform  any  geometric 
computation  exactly.  Exact  arithmetic  allows  programmers  to  construct  simple  and  assuredly 
robust  implementations  of  geometric  algorithms. 

Despite  the  luxuries  it  affords  programmers,  exact  arithmetic  has  been  "out  of  the  mainstream" 
for  commercial  geometric  programs.  Once  integers  are  allowed  to  grow  to  an  arbitrary  size, 
rather  than  being  neatly  restricted  to  a  single  machine  word,  implementation  in  a  language 
without  automatic  storage  management  becomes  extremely  tedious.  Integers  must  be  explicitly 
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allocated  and  deallocated  constantly,  which  makes  software  more  complex.  A  Delaunay  trian¬ 
gulation  algorithm  using  rational  numbers  implemented  in  C  spent  70  percent  of  its  time  in 
MALLOC  ajnd  FREE  (storage  management  functions)  [Karasick  1991],  although  this  amount  was 
later  reduced  by  preallocating  space  for  small  integers. 

Exact  arithmetic  is  a  standard  feature  of  Lisp  and  has  been  for  decades.  Consequently,  big  inte¬ 
gers  (BIGNUMs)  and  rationals  can  be  manipulated  by  exactly  the  same  programs  that  manipu¬ 
late  floating-point  numbers  and  integers  that  fit  into  machine  words.  Storage  management  for 
numbers  is  performed  by  the  sanrve  system  that  maxtages  storage  for  functions  and  data  structures. 
Despite  decades  of  improvements  in  low-level  implementations  of  BIGNUMs,  even  Lisp  pro¬ 
grammers  often  resort  to  floating-point  to  achieve  faster  execution  speed. 

Despite  defections  to  floating-point,  the  Lisp  community  has  nurtured  significant  work  on  exact 
arithmetic  using  continued  fractions  to  represent  computable  real  numbers.  Bill  Gosper,  the  leg¬ 
endary  pioneering  Lisp  hacker,  opens  his  privately  distributed  work  on  continued  fractions  by 
admitting  that  "people  who  like  continued  fractions  eat  pickled  okra  and  drive  Citroens  ...  [1 
feel  pity]  for  everyone  who  must  crunch  his  numbers  decimally  or  cast  his  points  to  float  among 
electroruc  registers."  As  if  to  prove  Gosper's  point  about  Citroens,  the  most  practical  and  com¬ 
plete  continued  fraction  system  has  been  implemented  in  LeLisp  [Vuillemin  1988;  Vuillemin 
1987]. 

"A  future  so  bright,  you'll  need  to  wear  sunglasses"  —  this  appears  to  be  the  case  for  exact 
arithmetic.  The  havoc  wreaked  by  floating-point  imprecision  on  geometric  algorithms  has  at¬ 
tracted  the  attention  of  academics,  with  survey  articles  [Farouki  1989;  Hoffmann  1989),  papers 
focusing  on  using  exact  arithmetic  in  certain  applications  [Karasick  1991],  and  attempts  to  tame 
the  floating-point  monster  [Guibas  1989;  Milenkovic  1988].  Possibly  more  important  for 
practical  applications,  computer  architects  are  designing  special  hardware  for  rapidly 
performing  exact  or  high-precision  calculations.  Modest  hardware  parallelism  and  modular 
arithmetic  permit  9()0-bit  operations  to  proceed  at  speeds  comparable  to  standard  workstations 
performing  double-precision  calculations  [Wu  1989].  Gosper's  work  has  inspired  bit-serial 
processor  designs  for  exact  rational  arithmetic  [Komerup  and  Matula  1987]. 

5.1.6.  Compactness 

Marcel  Proust's  A  la  recherche  du  temps  perdu  is  supposedly  one  of  the  20th  century's  greatest 
novels.^  However,  few  will  appreciate,  much  less  fully  understand,  its  3300  pages  filled  with 
tangled  sentences.  A  200,(XX)  line  computer  program  is  similarly  inaccessible  to  a  newcomer  and 
modifications  made  by  people  without  a  comprehensive  understanding  of  the  program  often 
have  unintaided  effects.  A  programmer  who  doesn't  understand  Proust  might  be  at  a 
disadvantage  in  a  Parisian  salon;  a  programmer  who  doesn't  understand  the  200,000  line 
program  he  is  modifying  usually  generates  bugs  and  concomitant  user  suffering.  Much  effort  has 
been  devoted  toward  making  programs  harder  to  break  and  many  computer  languages,  notably 


^Proust  (1871-1922)  might  have  made  a  good  hacker.  Maintaining  that  "real  books  should  be 
the  offspring  not  of  daylight  and  casual  talk  but  of  darkness  and  silence,"  he  secluded  himself 
in  a  cork-lini^  room  where  he  wrote  from  1905  until  his  death  in  1922. 
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ADA,  were  designed  specifically  with  this  goal  in  mind.  There  is,  however,  no  substitute  for 
compactness. 

A  100  line  program  is  almost  always  easier  to  understand  than  a  10,000  line  program.  Smaller 
programs  have  fewer  bugs  and  cost  less  to  produce.  Although  native  language  power  affects 
program  size,  abstraction  is  the  primary  means  for  reducing  program  size  and  perceived  com¬ 
plexity.  A  bug  in  an  algorithm  is  much  easier  to  spot  if  the  algorithm  is  not  surrounded  by  '  el- 
evant  declarations,  data  type  conversions,  data  structure  manipulations,  storage  management 
function  calls,  etc.  Factoring  a  system  into  procedures  that  are  widely  shared  also  facilitates 
compactness  and  debugging.  Consider  an  algorithm  implementation  where  95%  of  the  work  is 
done  by  helper  procedures  that  have  been  in  use  for  years  by  other  algorithms.  A  programmer 
can  assume  that  the  helper  procedures  are  functioning  correctly  and  focus  his  attention  on  the 
5%  of  the  code  that  is  new.  Such  assumptions  are  sometimes  wrong,  but  general-purpose  pro¬ 
cedures  used  in  dozens  of  places  are  generally  nK>re  reliable  than  freshly<onstructed  code. 

5.2.  Environment  Requirements 

Even  with  the  choice  of  programming  language  held  fixed,  software  development  productivity 
is  affected  dramatically  by  the  programming  environment.  I  decided  upon  the  following  set  of 
desirable  features: 

•  incremental  compilation  and  dynamic  linking 

•  interactive  debugging,  including  ability  to  restart  computation 

•  algorithm  arumation  tools,  including  steppers 

•  metering  tools 

•  window  system  and  user  interface  tools  extendible  via  a  class  hierarchy 

Unfortunately,  when  1  started  writing  SITE  CONTROLLER  in  1986,  no  programming  environment 
included  all  the  features  I  wanted. 

5.3.  Choosing  the  Lisp  Machine 

Common  Lisp  and  the  Symbolics  Lisp  Machine  fulfilled  nearly  all  the  requirements  I  set  fordi 
for  both  programming  language  and  environment.  The  Lisp  Machine's  hardware  and  operating 
system  support  for  clever  garbage  collection  algorithms  enabled  me  to  work  for  weeks  without 
rebooting  the  machine  or  thinking  about  storage  allocation.  Although  the  Common  Lisp  Object 
System  was  not  standardized  when  SITE  CONTROLLER  was  begun,  the  Lisp  Machine  Flavor 
system  contained  virtually  everytfiing  I  needed  except  the  ability  to  dispatch  on  the  type  of 
two  arguments  (i.e.,  operations  such  as  INTERSECT  were  difficult  to  express  elegantly). 

Common  Lisp  itself  provides  ample  facilities  for  writing  higher-order  procedures  and  per¬ 
forming  metalinguistic  abstraction.  Although  Common  Lisp's  formal  model  of  arithmetic  has 
proven  helpful  when  porting  SITE  CONTROLLER,  I  was  forced  to  use  floating-point  arithmetic 
rather  than  Common  Lisp's  exact  aridimetic  due  to  the  anemic  performance  of  the  1  MIPS 
Symbolics  processor.  Finally,  Common  Lisp  allowed  me  to  express  computation  concisely  and 
the  core  of  SITE  CONTROLLER  is  little  more  than  10,000  lines  of  code  as  a  consequence. 
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The  programming  envirorunent  on  the  Symbolics  machine  that  I  used  back  in  1986,  or  for  that 
matter  on  the  MIT  Lisp  Machine  I  used  back  in  1979,  is  vastly  superior  to  programming 
environments  on  modem  computers  (see  [Greenblatt  1984;  Walker  1987]).  In  addition  to 
incremental  compilation  and  dynamic  linking,  a  flexible  debugger,  a  class-based  window  sys¬ 
tem  extendible  at  run-time,  elaborate  metering  tools,  and  rudimentary  algorithm  animation, 
the  Lisp  Machine  provided  a  seamless  working  environment  where  general  rules  and  concepts 
made  it  possible  to  exploit  the  full  power  of  even  unfamiliar  comers  of  the  operating  system 
and  programming  tools. 
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6.  StTE  Controller  Description 

6.0.  System  Overview 


Figure  6.0  System  Overview. 
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SITE  CONTROLLER  as  described  in  this  report  may  be  broken  up  into  the  following  components; 

•  base  M.I.T.  Lisp  Machine  system  software 

•  PHILG  substrate  system,  proving  some  simple  graphics  and  user  interface  extensions 

•  LAND  HACKER  core  system,  where  most  of  the  site  modelling  and  analysis  is  done, 
as  well  as  much  of  the  user  interface 

•  Mine  plaiming,  an  extension  of  LAND  HACKER  to  model  three-dimensional 
subsurface  mineral  seams 

•  Actor  simulation,  a  framework  for  modelling  vehicles  and  people 

•  Site  Controller,  per  se,  an  extension  of  the  actor  simulator  to  communicate  with, 
morutor,  and  control  real  construction  vehicles 

The  overriding  system  design  philosophy  in  SITE  CONTROLLER  is  extension  via  subclasses.  As 
much  of  the  basic  M.I.T.  Lisp  Machine  operating  and  window  system  was  retained  as  possible. 
Unless  a  native  Lisp  Machine  facility  was  horribly  ugly  or  slow,  I  extended  it  with  a  method  or 
two  and  used  rather  than  implement  something  from  scratch.  In  practice,  only  the  basic 
language,  window,  and  multiprocessing  systems  were  really  useable.  Many  of  my  extensions 
were  salvaged  from  previous  applications  and  I  collected  them  up  into  the  arbitrarily-named 
'THILC  substrate  system"  (philg@mit.edu  is  my  Internet  address). 

LAND  HACKER  is  the  core  system  that  performs  all  of  the  functions  necessary  for  site  design 
and  maintains  the  precious  site  database.  LAND  HACKER  can  stand  by  itself  as  a  tool  for  a 
civil  engineer  and  is  complete  with  many  user  interface  methods.  Given  all  of  the  surface 
manipulation  facilities  built  into  LAND  HACKER,  the  mine  planning  extension  was 
surprisingly  painless. 

A  much  more  significant  effort  was  required  te  layer  a  general  purpose  actor  simulator  on  top  of 
LAND  HACKER  and  define  appropriate  class  behavior  for  earthmoving  vehicles.  When 
Caterpillar  wanted  to  use  the  system  for  real  world  vehicle  monitoring  and  control,  I  spent  a 
few  weeks  extending  the  actor  simulator  and  adding  a  packet  communications  module. 

This  section  makes  for  rather  heavy  going  at  times  and  for  that  I  apologize.  However,  much  of 
the  elegance  of  SITE  CONTROLLER  lies  in  the  integration  and  the  details;  I  could  find  no  way  to 
pick  out  the  highlights  and  make  them  comprehensible  on  their  own. 
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6.1.  PHILG  Substrate  System 


The  PWLG  substrate  system  was  adapted  from  previous  Lisp  Machine  efforts  involving  similar 
graphics  display  and  user  interface  problems.  Principal  facilities  of  the  PHILG  system  include 
user  interface  functions  and  window  system  extensions  for  graphics  and  plotting. 

6.1.1.  Graphics  and  Plotting 

The  VIEW-MIXIN  class  can  be  combirted  with  any  Lisp  Machine  window  to  allow  the  users  of 
the  window  to  perform  operations  in  a  projection  plame;  i.e.,  all  the  drawing  methods  and  user 
interface  methods  scale  automatically  between  a  programmer-specified  projection  plane  region 
and  the  actual  pixels  occupied  on-screen  b j  the  window.  In  addition  to  scaling  and  obvious 
graphics  drawing  commands,  the  class  contributes  methods  for  centering  or  justifying  text,  a 
method  for  getting  a  mouse-specified  rectangle  from  the  user  in  projection  coordinates,  and 
methods  for  zooming  and  scrolling.  Virtually  every  window  in  the  SITE  CONTROLLER  system 
inherits  from  this  class. 

A  simple  2D  plotting  package  is  rolled  into  yet  another  window  class  (PLOTTING-VIEW- 
MIXIN).  This  can  be  used  to  both  present  data  to  and  capture  data  from  the  user,  i.e.,  a  program 
can  take  input  from  a  user  sketching  a  curve  or  touching  points  on  a  graph. 

HAREXZOPYING-VIEW-MIXIN  is  a  class  that,  when  mixed  into  any  window  inheriting  from 
the  VIEW-MIXIN  class,  sends  output  simultaneously  to  the  screen  and  a  printer.  Mostly,  this 
code  consists  of  a  set  of  .  AFTER  methods  that  will  be  combined  with  the  primitive  drawing 
commands  of  VIEW-MIXIN.  Every  time  a  drawing  message  is  sent  to  a  window  inheriting  from 
both  VIEW-MIXIN  and  HARDCOPYING-VIEW-MIXIN,  a  primary  method  from  VIEW- 
MIXIN  executes  first  to  draw  on  the  screen  then  an  .AFTER  method  from  HARDCOPYING- 
VIEW-MIXIN  is  invoked  t^  send  appropriate  commands  to  a  printer.  There  are  also  methods 
here  for  turning  the  hardcopy  shadow  on  arni  off. 

6.1.2.  User  Interface  Facilities 

PHILG  contains  a  system  for  automatically  assembling  a  keyboard  and  mouse  user  interface, 
complete  with  on-ime  help,  from  distributed  command  definitions.  By  building  the  overall 
system  "frame"  to  inherit  from  KEYBOARD-COMMANDS-MIXIN,  the  progranuner  would  en¬ 
sure  that,  at  system  startup,  a  keyboard  command  data  structure  would  be  created  by  methods  of 
this  class.  By  defining  the  method  combination  for  the  :KEYBOARD-COMMANDS  operation 
to  be  :APPEND,  any  class  with  commands  to  contribute  need  only  define  a  method  for  this  oper¬ 
ation  that  returns  a  list  of  those  commands.  At  startup,  the  lists  would  be  appended  by  the  Lisp 
Machine  object  system  and  returned  as  the  result  of  the  operation  :KEYBOARD-COMMANDS. 

Here  is  an  example  of  the  code  to  define  a  single  keyboard  command: 

(def ine-keyboard-command  #\help  :coiTiinand-help  'Display  helpful 
information') 
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This  says  that  when  the  HELP  key  is  pressed,  send  the  frame  the  message  KTOMMAND-HELP 
and  that,  if  asked  for  help  about  what  this  key  does,  print  that  it  will  "Display  helpful  in¬ 
formation". 

MOUSE-COMMANDS-MIXIN  works  similarly,  except  that  each  window  in  the  frame  has  its 
own  data  structure  for  handling  mouse  clicks.  On  a  Symbolics  machine,  there  are  three  mouse 
buttons  and  five  shift  keys  (SHIFT,  CONTROL,  META,  SUPER,  and  HYPER),  thus  allowing  96 
possible  mouse  clicks.  MOUSE-COMMANDS-MIXIN  constructs  two  interfaces.  The  first  al¬ 
lows  novices  to  choose  commands  from  a  menu  by  rolling  the  mouse  over  various  command  names 
while  viewing  short  descriptions  of  each  command  in  the  Lisp  Machines  documentation  line 
near  the  bottom  of  the  screen.  Experienced  users  invoke  comands  with  mouse  chords,  i.e.,  by 
holding  down  a  combination  of  shift  keys  witti  the  left  hand  and  pressing  one  of  the  three 
mouse  buttons  with  the  right. 

The  beauty  of  this  implementation  is  that  commands  and  on-line  documentation  cannot  get  out 
of  sync.  Whenever  one  defines  a  command,  one  must  supply  documentation  that  the  system 
automatically  feeds  to  the  user  at  appropriate  times.  Commands  and  documentation  are 
similarly  removed  atomically. 

More  traditional  user  interface  support  is  provided  by  the  class  INTERAc  1 1 VE-VIEW-MIXIN. 
There  are  methods  tfiat  "rubberband"  lines,  piecewise-linear  curves,  rectangles,  circles  and  el¬ 
lipses  while  the  user  manipulates  the  mouse.  The  user  plays  with  a  shape  by  moving  the 
mouse,  sees  the  shape  at  all  times,  and  specifies  the  shape  by  touching  a  mouse  button  or  the 
END  key.  The  .-GENERIC-MOUSE-HANDLER  method  nicely  illustrates  the  power  of  higher- 
order  procedures.  This  method  takes  a  2x2x2x2  matrix  (corresponding  to  the  states  of  the 
HYPER,  SUPER,  META  and  CONTROL  shift  ke)rs)  as  its  argument.  Each  entry  is  a  list  of  four 
procedures  and  a  documentation  string  describing  the  effect  of  each.  The  method  tracks  the 
user's  mouse  movements  and  applies  the  appropriate  procedure  after  each  mouse  move  (there 
are  three  buttons  on  a  Lisp  Machine  mouse  and  hence  one  needs  four  procedures,  one  for  each 
button  plus  one  for  "no  buttons  pressed.") 

What  is  imjTortant  about  :GENERIC-MOUSE-HANDLER  is  that  the  user  procedures  are 
spared  from  so  many  messy  details  of  the  Lisp  Machine  window  system:  1)  understanding  how 
to  "grab"  the  mouse  and  ensure  that  all  mouse  action  is  reported  to  this  window;  2)  figuring  out 
an  efficient  method  of  detecting  mouse  moves  smoothly;  and  3)  sensing  the  state  of  four  shift 
keys  and  updating  dte  documentation  line  appropriately  as  the  user  presses  shift  keys.  User 
procedures  are  thus  much  smaller  and  more  portable  across  window  systems. 

For  use  interactions  that  are  global  in  nature,  i.e.,  not  restricted  to  a  single  view, 

INTERACT  !  VE-FRAME-MIXIN  is  a  class  that  contributes  numerous  user  interface  methods  to 
any  frame  that  inherits  from  it.  Notably  these  include  methods  to  prompt  and  query  the  user, 
to  display  output  on  a  special  roll-down  "typeout"  window,  and  similar  methods  that  shield 
the  rest  of  the  program  from  Lisp  Machine  window  and  I/O  system  details. 
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6.2.  LAND  HACKER  Core  System 
6.2.1.  Geometry  and  Graphics  Substrate 


This  2D  and  3D  geometry  substrate  includes  simple  vector  manipulation  procedures  suet,  as 
addition,  dot  product,  cross  product,  scalar  multiplication,  and  normal  vector  construction. 
Slightly  more  complex  are  a  full  complement  of  transform  operations  such  as  "rotate  about 
point."  Oriented  lines  are  modelled,  and  there  are  primitives  for  determining  on  which  side  of 
a  line  a  point  falls,  the  distance  of  a  point  from  a  line,  and  segment  intersection.  Polygon, 
parallelogram,  and  segment  objects  are  defined  and  are  sufficiently  full-bodied  to  know  how  to 
draw  themselves. 

The  3D-VIEW-MIXIN  class  gives  a  window  the  capability  of  displaying  perspective  and 
parallel  projections  of  3D  objects.  This  class  supports  the  programmer  by  enabling  a  window  to 
automatically  scale  itself  to  fit  a  3D  bounding  box,  i.e.,  ensure  that  everything  irtside  that  box 
will  be  visible  in  the  window. 

6.2.2.  Surface  Modelling  Data  Structures 

Civil  engineering  surface  modelling  can  be  broken  up  into  two  problentts: 

•  given  a  set  of  points  of  known  elevation,  interpolate  a  surface  through  those  points 
that  accurately  and  efficiently  represents  the  site 

•  capture  from  the  user  and  represent  a  model  of  what  the  site  should  look  like 
A  good  surface  model  for  civil  engineering  must  have  the  following  characteristics: 

•  ability  to  model  different  areas  of  the  site  at  different  levels  of  detail,  i.e.,  a  uniform 
grid  is  inadequate 

•  ability  to  faithfully  reflect  site  topology,  i.e.,  features  such  as  ridges  and  streams 

Older  surface  modelling  programs  tend  to  use  fixed  regular  rectangular  grids  to  represent 
surfaces.  Scattered  survey  data  is  used  to  calculate  the  elevations  of  every  grid  point. 
Elevations  of  query  points  are  interpolated  using  a  few  nearby  grid  points.  The  principal 
shortcomings  of  this  technique  are  that  all  areas  of  the  surface  are  represented  at  the  same 
level  of  detail,  which  means  that  a  need  for  fine  detail  in  even  a  small  comer  implies  an 
enormously  large  grid,  and  that  site  topology  cannot  be  reflected,  i.e.,  ridge  and  stream  lines 
may  be  blurred. 


6. 2. 2.1.  Triangulated  Irregular  Networks 

SITE  CONTROLLER,  along  with  most  modem  surface  modelling  software,  uses  a  triangulated  ir¬ 
regular  network  (TIN)  [Peucker  1978;  Fowler  and  Little  1979].  Looking  down  at  a  planar  map  of 
a  set  of  surveyed  points,  consider  the  smallest  convex  polygon  that  contains  all  the  points,  the 
convex  hull  of  the  points.  The  convex  hull  is  shaped  like  a  rubber  band  stretched  around  the 
points.  Now  connect  the  points  so  that  the  interior  of  the  convex  hull  consists  of  triangl*  whose 
vertices  are  surveyed  points  (see  Figure  6.1).  This  is  a  TIN  model  of  the  site. 
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Figure  6.1  (a)  Surveyed  points  and  convex  hull;  (b)  interior  of  convex  hull  triangulated. 

6. 2. 2. 2.  Piscswisa-Planar  Modal 

Three  (non-coUinear)  points  determine  a  plane.  Each  triangle  vertex  is  a  surveyed  point,  i.e.,  a 
point  whose  elevation  is  known.  Thus,  we  may  obtain  a  piecewise-planar  surface  model  of  the 
site  simply  by  regarding  each  triangle  as  a  section  of  a  plane.  This  looks  something  like  the 
faceted  surface  of  a  cut  diamond,  although  a  gem  would  have  much  more  relief  than  a  typical 
civil  engineering  site.  This  is  a  C®  model  of  the  surface,  i.e.,  there  are  no  holes,  but  the  first 
derivative  is  discontinuous  at  the  triangle  edges.  Aldiough  crude,  a  linear  fit  has  the 
advantages  of  computational  speed  and  faithfulness  to  manually-surveyed  data.  Surveyors  are 
instructed  to  record  a  point  at  every  slope  change  and  are  thus  already  fitting  a  piecewise- 
planar  surface  to  the  site  in  their  heads. 

A  SrTE  CONTROLLER  surface  model  consists  of  sur/eyed  points  connected  by  edges  in  a 
triangulation. 


6. 2. 2. 3.  Surveyed  Points 

Surfaces  are  abstract  mathematic2il  entities  constrained  to  pass  through  a  set  of  specified 
points.  Each  point  is  represented  by  an  instance  of  the  class  SURVEYED-POINT  that  contains 
the  following;  x,y,z  coordinates;  a  pointer  to  the  surface  of  which  it  is  a  part;  a  list  of  other 
points  to  which  the  particular  point  is  corvnected  in  a  triangulation;  a  list  of  triangles  of  which 
this  point  is  a  vertex;  a  list  of  edges  of  which  this  point  is  an  endpoint;  and  provision  for 
annotations  such  as  how  the  point  was  generated  (e.g.  designer  input,  surveyed  data  measured 
by  Joe  Surveyor,  data  automatically  collected  from  a  bulldozer,  etc.). 

In  addition  to  straightforward  methods  for  managing  their  data  structures,  surveyed  points  are 
responsible  for  a  lot  of  the  work  in  building  the  overall  surface  model.  For  example,  it  is  the 
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surveyed  points  that  create  edges.  Surveyed  points  also  have  methods  that  aid  hydrological 
analysis  plus  the  usual  :DRAW-SELF,  :HIGHLIGHT-SELF,  and  :UNHIGHLIGHT-SELF  meth¬ 
ods  that  enable  surveyed  points  to  work  smootfily  with  the  SITE  CONTROLLER  user  interface. 

6. 2. 2. 4.  Triangles 

Triangles  are  instances  of  the  fairly  simple  class  TRIANGLE.  Each  instance  stores  the  three 
vertices  and  a  specification  for  the  type  of  terrain  (e.g.  silty  sand),  caches  oriented  2D  lines  for 
each  edge  (useful  for  answering  point  inclusion  queries)  and  also  the  direction  of  the  gradient  of 
the  plane  that  passes  through  the  three  vertices. 

A  triangle  is  a  remarkably  capable  object,  able  to  say  whether  a  query  point  is  inside  itself, 
which  of  its  edges  are  cut  by  a  ray  (useful  for  problems  such  as  intervisibility),  what  the 
elevation  at  any  included  query  point  is,  the  location  of  Its  centroid,  and  its  2D  area.  Triangles 
also  provide  the  active  methods  for  drawing  and  armotating  contour  lines,  as  well  as  standard 
user  interface  methods  for  drawing,  highlight  and  unhighlighting. 

6. 2. 2. 5.  Edg«s 

Edges  in  the  triangulation  are  full-fledged  objects.  Here  we  have  traded  space  for  speed  in  a 
particularly  profligate  marmer.  Only  two  pointers,  one  for  each  surveyed  point,  need  be  kept 
and  yet  an  object  of  the  class  EDGE  contains  no  fewer  than  16  instance  variables.  There  are 
representations  of  each  point  as  a  2D  and  3D  vector,  a  normal  vector  in  the  direction  of  the  edge, 
a  full  size  vector  pointing  from  POINT-1  to  POINT-2,  an  oriented  line  through  the  two  surveyed 
points,  and  a  collection  of  information  about  elevation  that  is  useful  when  contouring. 

An  edge  is  capable  of  interpolating  along  the  line  passing  through  its  endpoints,  intersecting  it¬ 
self  with  a  line  segment  (both  in  space  and  in  projection  onto  the  x-y  plane),  saying  whether  a 
point  is  to  the  left  or  the  right  of  tt\e  edge  (in  a  2D  projection),  helping  the  program  walk 
through  the  data  structure  finding  all  edges  cut  by  a  ray,  determining  whether  it  is  a  stream  or 
a  ridge,  and  interacting  with  the  user  interface. 

6.2.3.  Triangulation 

Accuracy  in  a  triangulated  surface  model  is  intimately  dependent  upon  the  triangulation  of  the 
points,  i.e.,  which  points  are  cormected  to  which  other  points.  If  triangles  are  long  and  skinny, 
the  interpolated  elevation  of  a  query  point  will  depend  on  far  away  surveyed  points  despite 
the  existence  of  nearby  surveyed  points  that  are  probably  more  indicative  of  tfie  query  point's 
true  elevation.  It  is  therefore  desirable  to  choose  a  triangulation  where  most  of  the  triangles 
are  close  to  being  equilateral. 

If  a  triangle  cuts  through  a  ridge  or  wall,  interpolated  elevations  on  one  side  of  the  ridge  are  in¬ 
fluenced  by  surveyed  points  on  the  odier  side  and  the  ridge  itself  may  be  obscured.  Choosing  a 
triangulation  where  the  edges  coincide  with  the  ridge  ensures  that  accuracy  is  maintained  and 
that  the  surface  model  remains  faithful  to  the  topology  of  the  site. 
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8. 2. 3.1. 


□•launay  Triangulation 


There  are  numerous  ways  to  measure  the  "equilateralness"  of  a  triangulation.  Consider  a 
triangulated  quadrilateral,  i.e.,  one  broken  up  into  two  triangles  by  a  diagonal  line.  If 
switching  the  triangulation  to  use  the  alternative  diagonal  would  not  increase  the  minimum  of 
the  six  interior  angles,  then  the  triangulation  is  said  to  be  locally  equiangular.  Note  that 
small  minimum  angle  is  bad,  corresponding  as  it  does  to  a  long,  skirmy  triangle.  Determining 
global  equiangularit}’  is  more  complicated.  First  of  all,  one  must  use  Euler's  relation  to  show 
that  any  triangulation  of  n  non-collinear  sites  in  the  plane  must  contain  exactly 
m  =  2n  —  2  —  k  triangles,  where  k  is  the  number  of  boundary  edges,  i.e.,  the  edges  of  the 
convex  hull.  Thus,  every  triangulation  of  a  set  of  points  has  a  total  of  3m  interior  angles  and 
the  sum  of  those  angles  is  mjt. 

Next,  consider  the  set  of  interior  angles  indexed  so  that  Of,  ^  (Xj  if  /  <  y.  An 

alternate  set  of  interior  angles,  i.e.,  from  an  alternate  triangulation  of  the  same  points, 
(Ofi'.flfj.K  .Ofj^)  is  said  to  be  less  than  (i.e.,  worse  than)  the  original  set  if  there  is  an  index 
1  <  j<3m  such  that  a'  <  ar>d  a\  -  a,  for  1  <  i  <  y .  A  triangulation  is  said  to  be  globally 

equiangular  if  all  other  possible  triangulations  are  less  than  it,  i.e.,  that  its  sorted  list  of 
angles  gets  "big"  faster  than  any  other  trianguiation's. 

The  Delaunay  triangulation  is  locally  equiangular,  which  has  been  shown  to  be  equivalent  to 
global  equiangularity,  and  is  the  only  such  triangulation  [Edelsbrunner  l9o/J.  Althou^  there 
are  many  ways  of  generating  the  Delauruiy  trianguladon,  an  easy  way  to  see  it  is  as  the  dual  of 
the  Voronoi  Diagram.  Consider  a  set  of  points  Pi.P2»^  ^Ph-  Voronoi  polygon  of  p,  is  the 
region  of  query  points  closer  to  Pj  than  to  any  other  point  p . 

A  ruive  method  of  generating  the  Voronoi  polygon  of  a  point  p,  is  to  construct  the  perpendicu¬ 
lar  bisector  of  each  pair  of  points  [(p.Py)  i*  j]  and  intersect  the  half-planes  containing  p-. 
The  resulting  polygon  is  the  Voronoi  polygon  of  p .  Note  that  constructing  a  Voronoi  Diagram 

that  shows  the  Voronoi  polygon  for  each  of  n  points  requires  C?(n^)  time  if  carried  out  in  this 
naive  manner. 
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Figure  6^  Voronoi  Diagram  (dashed  lines  enclosing  regions  of  plane  closest  to  a  par¬ 
ticular  point)  and  its  dual,  the  Delaunay  triangulation  (solid  lines  connecting  points 
whose  Voronoi  polygons  are  adjacent). 

Connecting  pairs  of  points  that  share  an  edge  in  the  Voronoi  Diagram  generates  the  Delaunay 
triangulation  of  the  set  of  points  in  (Xn)  time  (see  Figure  6.2).  Considering  the  number  of 
surveyed  points  in  a  constructicm  site,  and  the  number  that  are  added  in  real  time  by  the 
activity  of  construction  vehicles,  the  Delaunay  triangulation  would  not  be  very  useful  if  it 
required  O(n^)  time  (to  construct  ttte  Voronoi  diagram  and  then  the  triangulation). 

Fortimately,  there  are  numerous  0(n  log /i)  algorithms  to  construct  Voronoi  diagrams,  the  most 
elegant  of  which  is  a  plane  sweep  algorithm  [Fortune  1987].  There  are  also  efficient  algorithms 
for  constructing  Delaunay  triangulations  directly  [Aurenhammer  1991]. 

6. 2. 3. 2.  Constrained  Delaunay  Triangulation 

Although  using  the  Delaunay  triangulation  by  and  large  solves  the  problem  of  inaccuracy  due 
to  skinny  triangles,  the  problem  of  the  triangulation  not  faithfully  representing  the  topology 
remains.  We  would  like  to  constrain  the  model  so  that  certain  edges  are  preserved,  i.e.,  certain 
points  are  coimected  to  certain  other  points.  We  would  then  like  to  generate  the  triangulation 
that  is  closest  to  the  Delaunay  triangulation  subject  to  those  constraints,  i.e.,  the  Constrained 
Delaunay  triangulation.  It  is  possible  to  construct  a  Constrained  Delaunay  triangulation  or  its 
dual,  a  constrained  Voronoi  diagram,  in  O(nlogn)  time  and  0(/i)  space  using  a  plane  sweep 
algorithm  [Aurenhammer  1991].  This  is  an  important  result,  for  if  exponential  time  were 
required,  die  utility  of  triangulation-based  construction  automation  software  might  be 
restricted  to  toy  problems. 

Given  this  rich  body  of  literature,  what  path  did  I  choose  for  SITE  CONTROLLER?  Well,  Jim 
Little  and  I  spoit  an  afternoon  translating  one  of  his  ancient  3000-line  PL/I  Delaunay 
triangulation  programs  into  a  150-line  Common  Lisp  program.  This  is  not  an  efficioit  algo¬ 
rithm,  taking  O(n^)  time  to  do  an  O(nlog/i)  job,  but  since  our  initial  data  sets  were  small,  it 
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didn't  seem  worth  spending  a  lot  of  time  trying  to  implement  an  optimal  algorithm  from  the 
literature. 

Once  the  Delaunay  triangulation  is  complete,  it  is  corrupted  by  a  brute  force  lii\king  of  points 
that  are  paired  up  in  forced  connections  usually  to  respect  the  topology.  The  data  structures  are 
then  fleshed  out,  with  surveyed  points  being  linked  to  newly  created  edge  objects  and  vice 
versa.  Finally,  triangles  are  created  and  doubly  linked  to  the  points.  Finding  all  the  triangles 
is  not  as  simple  as  it  sounds,  since  most  obvious  algorithms  will  find  too  many  triangles,  i.e., 
ones  that  contain  other  triangles. 

6.2.4.  Surfaces 

Surfaces  are  represented  by  instances  of  the  class  SURFACE.  The  class  definition, 
initialization  values,  user  interface  for  editing  surface  parameters,  and  information  about 
which  instance  variables  to  save  in  a  site  database  are  all  obtained  from  one  list  of  lists,  each 
sublist  of  which  has  the  following  form; 

(name  rname  nil  :set-neune  t  t  : string-or-nil  t) 

This  list  specifies  the  instance  variable  NAME,  with  get  message  ;NAME,  initial  value  NIL, 
and  set  message  :SET-NAME.  The  last  four  values  declare  the  variable  to  be  both  user-visible 
and  user-settable,  inform  the  user  interface  code  to  accept  only  strings  or  NIL  as  valid  NAMEs, 
and  ensure  that  this  value  will  be  saved  along  with  a  surface. 

Once  again,  we  see  how  defming  something  this  way  ensures  that  the  data  structures  and  user 
interface  don't  get  out  of  sync. 

Information  carried  around  by  surfaces  includes  the  following; 

•  a  list  of  SL  eyed  points 

•  a  flag  inc.  ting  whether  those  points  are  connected  in  a  valid  triangulation 
(triangulatic  is  expensive  and  hence  only  done  when  necessary) 

•  a  list  of  triangles,  a  list  of  "interpolating  triangles"  capable  of  supporting  a  smooth 
surface  model  with  continuous  first  derivative  (these  take  up  a  lot  of  space  so  we  don't 
compute  them  uidess  the  user  asks  for  a  smooth  contour  map  or  something  else  for  which 
a  piecewise-planar  surface  model  is  inadequate) 

•  a  parameter  specifying  a  tradeoff  between  execution  speed  and  contour  smoothness 

•  a  list  of  forced  connections 

•  a  boundary  polygon  that  is  the  convex  hull  of  the  surveyed  points 

•  the  edges  of  the  boundary  polygon  (useful  for  contour  labelling) 

•  the  default  contour  approximation  spacing  to  be  used  when  the  user  sketches  in  contour 
lines  with  the  mouse  (specifies  how  far  apart  surveyed  points  are  to  be  laid  down  to 
approximate  the  continuous  contour) 

•  some  hydrology  modelling  parameters 

•  a  tolerance  for  cut-and-fill  display  that  specifies  when  a  difference  in  height  is  too 
small  to  be  worth  considering. 
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Surfaces  are  fairly  powerful  objects.  There  are  numerous  methods  for  maintaining  the  pointers 
among  point,  edge,  arid  triangle  data  structures.  There  is  a  method  for  forcibly  connecting  two 
p)oints  and  fixing  broken  edges  so  that  the  points  and  connections  still  constitute  a  triangulation. 
Most  queries  about  the  surface-modelling  data  structures  are  handled  as  messages  to  an  object  of 
the  class  SURFACE.  In  particular,  a  surface  can  return  a  list  of  edges  that  intersect  a  query 
segment  (useful  for  intervisibility  calculations,  for  example),  or  the  triangle  that  contains  a 
query  point,  or  whether  the  convex  hull  contains  a  query  point  at  all. 

Surfaces  can  respond  to  an  :ELEVATION-AT-POINT  message  with  the  inter]x>lated  z  at  any 
(x,y).  They  can  also  contour  themselves  if  supplied  with  a  graphics  window.  For  3D  line  draw¬ 
ings,  the  surface  is  able  to  supply  a  profile  corresponding  to  a  line  segment  cutting  the  triangula¬ 
tion. 

For  debugging  purposes,  surfaces  are  able  to  aiumate  some  of  their  computations  and  are  even 
able  to  give  themselves  a  random  shape. 

6.3.  Surface  Visualization 

Civil  engineers  must  visualize  surfaces  in  oroer  to  design  a  site  plan.  Architects  must  visualize 
surfaces  whoi  judging  aesthetics  of  proposed  earthmoving  projects.  Laymen,  especially 
government  officials,  must  visualize  surfaces  when  deciding  whether  or  not  to  approve  a 
project. 

Traditionally  civil  engineers  have  relied  on  contour  maps  to  visualize  surfaces.  A  contour  map 
is  created  by  drawing  toe  intersection  of  a  surface  with  a  collection  of  evenly-spaced  horizontal 
planes.  Contour  maps  are  easily  generated  by  draftsmen  and  civil  engineers  quickly  learn  to  get 
a  feel  for  terrain  based  on  a  contour  map.  Urtforhinately,  laymen  have  great  difficulty 
visualizing  surfaces  with  contour  maps  and  even  experts  often  find  more  p>owerfuI  visualization 
tools  helpful. 

Ever  since  the  first  pen  plotters  were  introduced  in  toe  1950's,  surfaces  have  been  visualized 
with  line  drawings.  Laymen  can  acquire  some  insight  from  these  black  &  white  pictures.  The 
most  realistic  images  are  those  that  have  become  common  only  in  toe  1980's  with  toe  advent  of 
the  3D  workstation.  By  shading  polygons  with  different  colors  depending  on  toe  terrain,  inten¬ 
sities  depending  on  toe  angle  relative  to  light  sources,  and  patterns  depending  on  the  texture  of 
the  surface,  it  is  possible  to  obtain  images  of  great  realism. 

6.3.1.  Contour  Mapping 

Contour  mapping  is  easy  on  a  piecewise-planar  surface.  For  each  triangle,  one  simply  draws  a 
line  segment  between  toe  points  where  toe  horizontal  contour  plane  cuts  the  edges.  These 
points  may  be  found  by  linear  interpolation  along  toe  triangle  edges.  SITE  CONTROLLER 
performs  contour  mapping  locally,  i.e.,  each  trifmgle  draws  what  contour  line  segments  pass 
through  itself.  Difficult  issues  in  contour  mapping  include  labelling  and  drawing  contour  maps 
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efficiently  with  pen  plotters.  These  issues  are  covered  by  a  comprehensive  survey  article 
[Sabin  1985]  but  I  did  not  attack  any  of  the  tough  problems  in  my  implementation. 

6.3.2.  Perspective  Line  Drawings 

SITE  CONTROLLER  contains  no  software  to  do  traditional  rendering  of  its  polygonal  surfaces. 
This  choice  was  made  because  of  tive  staggering  expanse  and  hence  scarcity  of  the  Symbolics  24- 
bit  color  display.  Furthermore,  since  so  many  standard  rendering  facilities  on  graphics 
workstations  were  available,  it  seemed  simpler  to  merely  generate  surface  descriptions  in  a 
form  readable  by  existing  rendering  programs  rather  than  reinvent  the  wheel.  However,  SITE 
CONTROLLER  does  contain  a  traditional  perspective  line  drawing  facility  for  black  &  white 
displays. 

Line  drawings  are  projections  of  the  intersection  of  a  surface  with  a  series  of  regularly  spaced 
vertical  planes.  Iterative  algorithms  tfwt  generate  such  drawings  are  commonly  implemaited 
in  FORTRAN,  PL/1,  or  C,  sometimes  requiring  titousands  of  lines  of  code  and  more  than  one  man- 
year  to  debug.  James  L.  Little  and  I  wrote  a  70-line  Common  Lisp  program  in  two  hours  that  ac¬ 
complishes  the  same  task.  The  program  illustrates  a  number  of  important  programming  tech¬ 
niques  and  is  therefore  presented  in  detail. 

Traditional  programs  such  as  multi-pass  compilers  serially  convert  data  from  one  format  to  an¬ 
other  until  the  desired  final  format  is  achieved.  Using  Lisp's  recursion  and  dynamic  storage  al¬ 
location,  a  program  can  decompose  a  problem  as  it  recurses,  then  incrementally  construct  the  so¬ 
lution  as  it  returns.  The  canonical  example  of  this  approach  is  a  rudimentary  compiler  that  as¬ 
sociates  code  with  each  node  in  a  parse  tree  arKl  then  collects  that  code  as  the  tree  is  collapsed. 

Our  algorithm  only  works  with  surfaces  defined  by  z(x,y)  so  that  the  surface  has  a  unique  ele¬ 
vation  for  a  given  point  in  the  x-y  plane — overhangs  and  caves  cannot  be  modelled. 
Furthermore,  we  take  advantage  of  the  fact  that  we  are  working  with  the  surface  of  the  earth 
and  need  only  show  one  side  of  the  surface.  For  example,  if  the  surface  is  a  small  oil  field  in 
Texas  with  a  5,000-meter-deep  hole  in  the  ground,  we  carmot  see  the  exterior  of  the  hole  poking 
out  from  underneath  our  surface  if  our  view  point  is  above  the  surface. 

6. 3. 2.1.  General  Algorithm 

First,  we  intersect  the  surface  with  a  series  of  vertical  planes  orthogonal  to  the  projection  of  the 
viewing  direction  onto  the  x-y  plane.  We  then  convert  each  intersection  into  a  list  of  line  seg¬ 
ments  (if  the  surface  is  not  piecewise-planar  we  must  approximate  higher-order  curves  in  a 
piecewise-linear  fashion,  something  we  would  have  to  do  anyway  for  most  output  devices)  and 
call  the  list  a  profile.  We  make  a  list  of  the  profiles  by  stepping  in  fixed  increments  along  the 
viewing  direction  projection  (if  profile  A  is  closer  to  the  view  point  than  profile  B,  then  A  pre¬ 
cedes  B  in  the  list). 
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Figure  63a  An  example  surface  intersected  by  two  vertical  planes. 


Figure  63b  A  real  site  in  New  Hampshire,  rendered  widi  60  proflles. 

We  accomplish  hidden-line  elimination  by  two  dimensional  clipping  against  a  horizon  on  the 
view  plane.  We  display  only  those  line  segments  (or  portions  of  line  segments)  whose  projec¬ 
tions  are  above  a  horizon  established  by  projecting  and  drawing  previous  profiles.  Our  initial 
horizon  is  a  "segment"  from  (—<»,—<»)  to  (+<»,— «*>)  so  that  anything  in  the  first  profile  is 
guaranteed  to  be  drawn. 
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The  core  function,  CUP,  takes  a  profile  and  existing  horizon  and  returns  that  portion  of  the  pro¬ 
file  that  was  visible  and  a  new  horizon.  OUTER-LCXDP  starts  off  the  recursion  with  all  the 
profiles  and  the  initial  horizon  by  calling  OUTER-LOOP-1.  OUTER-LOOP-1  checks  to  see 
whether  there  are  any  profiles  left  and,  if  so,  calls  CLIP  to  clip  the  first  remaining  profile 
against  the  horizon.  OUTER-LOOP-1  then  draws  whatever  visible  segments  CLIP  returned  and 
recurses  with  the  remaining  elements  of  the  profile  list  (the  CDR,  or  the  rest  of  the  list  after 
the  first  element)  and  the  new  horizon  returned  by  the  call  to  CLIP. 

6. 3. 2. 2.  Rscurslv*  clipping 

CLIP  takes  two  arguments.  The  first  argument  is  a  list  of  profile  segments  arul  the  second  is  a 
list  of  horizon  segments.  CLIP  uses  the  Conunon  Usp  multiple  value  facility  to  return  two  val¬ 
ues,  a  list  of  segments  to  draw  (that  part  of  ti\e  profile  that  was  visible)  and  a  new  horizon 
(also  a  list  of  segments). 

CUP  assumes  tt\at  the  segments  within  each  list  either  do  not  overlap  or  that  they  overlap  just 
at  their  endpoints.  The  segments  are  assumed  to  be  arranged  from  left  to  right  (in  order  of 
increasing  x)  and  it  is  assun^ed  that  the  horizon  exta\ds  at  least  as  far  in  both  directions  as  the 
profile. 

As  in  any  recursion,  we  first  check  for  termination  conditions.  If  the  list  of  horizon  segments  is 
empty,  we  signal  an  error  (since  the  horizon  should  extend  to  -«).  If  the  list  of  profile  segments 
is  empty,  we  are  done  and  return  NIL  (the  empty  list)  as  our  first  value  (the  list  of  segments  to 
draw)  and  the  remaining  horizon  list  as  the  new  horizon.  These  values  will  be  added  to  by  sur¬ 
rounding  calls  to  CLIP. 

Another  easy  case  is  when  the  first  profile  segment  is  completely  to  the  right  of  the  first  hori¬ 
zon  segment  (Figure  6.4). 


first  profile  segment 


Figure  6.4  The  first  profile  segment  does  not  overlap  the  first  horizon  segment.  In  this 
case  we  recurse,  passing  down  the  complete  profile  segments  list,  but  stripping  off  the 
first  horizon  segment  The  value  returned  by  this  call  to  CUP  cannot  simply  be  the 
value  of  tile  recursive  call,  however,  sitKe  that  would  result  in  the  loss  of  part  of  the 
horizon.  The  SEGMENTS-TO-DRAW  value  is  simply  whatever  the  recursion  returned, 
but  the  new  horizon  is  a  list  whose  CAR  is  the  horizon  segment  we  stripped  off  and 
whose  CDR  contains  the  horizon  segments  returned  by  the  recursive  call. 


6.3.2. 3. 


RmI  work 


We've  now  dealt  with  the  easy  cases  and  must  consider  the  case  where  there  is  some  overlap 
between  the  first  horizon  segment  and  the  first  profile  segment  (Figure  6.5  illustrates  two 
representative  cases). 


Figure  6.5  The  operation  of  CLIP-SEGMENTS,  (a)  AB  is  the  input  horizon  segment,  CD 
is  the  input  profile  segment,  MN  is  the  SEGMENT-TO-DRAW,  AM  arwl  MN  are  the 
NEW-HORIZON-SEGMENTS,  and  ND  is  the  REMAINING-PROHLE-SEGMENT. 
The  REMAINING-HORIZON-SEGMENT  is  NIL.  (b)  XY  is  the  input  horizon  segment, 
UV  is  the  input  profile  segment,  UQ  is  the  SEGMENT-TO-DRAW,  XP,  UQ,  and  QR  are 
the  NEW-HORIZON-SEGMENTS,  and  RY  is  the  REMAINING-HORIZON-SEG¬ 
MENT. 

The  key  idea  here  is  to  deal  with  as  small  a  part  of  the  problem  as  possible  and  let  the  recur¬ 
sion  do  the  rest  of  the  work.  CLIP  calls  CLIP-SEGMENTS  to  compare  the  two  segments  until  it 
hits  the  right  edge  of  either.  CLIP-SEGMENTS  returns  four  values.  The  first  is  a  segment  to 
draw  (at  most  one  can  result  from  the  intersection  of  a  single  profile  segment  and  a  single  hori¬ 
zon  segment).  The  seccmd  is  a  list  of  new  horizon  segments  lying  horizontally  between  the  left 
edge  of  the  original  horizon  segment  and  the  leftmost  ri^t  edge  of  either  segment.  This  list 
will  contain  between  one  and  three  elements  (one  if  the  profile  segment  was  entirely  below  the 
horizon,  two  if  the  left  edges  of  both  segments  were  aligrwd  and  they  intersected  somewhere  in 
the  middle,  and  three  if  the  profile  segment's  left  edge  was  to  the  right  of  the  horizon  seg¬ 
ment's  left  edge  and  they  also  intersected  in  the  middle). 

CUP-SEGMENTS  returns  as  its  tiiird  value  that  portion  of  the  profile  segment  that  extended 
beyond  the  ri^t  edge  of  the  horizon  segment.  The  fourth  value  is  that  portion  of  the  horizon 
segment  that  extended  beyond  the  right  edge  of  the  profile  segment.  At  most  one  of  these  will 
be  non-NIL  (both  will  be  NIL  if  the  segments'  right  edges  are  aligned,  otherwise  one  segment 
must  extend  beyond  the  other). 

Most  recursive  algorithms  in  Lisp  generally  completely  process  one  element  of  a  list,  strip  that 
off  and  recurse  with  the  rest  of  the  list.  CUP  is  unusual  in  that  it  sometimes  doesn't  completely 
process  the  first  element,  so  it  has  to  recurse  with  the  unhandled  piece  of  the  first  element  stuck 
CONSed  onto  the  rest  of  the  list  CLIP  is  also  imusual  in  that  it  is  recursing  down  two  lists  at 
once  and  returning  two  values. 
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So  CUP  calls  ite«lf  recursively,  with  the  first  argument  (profile  segments)  being  the  result  of  a 
ccmditional.  If  the  profile  segment  processed  on  this  call  extended  beyond  the  horizon  segment 
processed,  we  strip  off  the  entire  first  profile  segment  (using  CDR),  but  stick  on  the  piece  of  the 
first  profile  segmait  that  we  didn't  handle  (the  REMAINING-PROFILE-SEGMENT  value  re¬ 
turned  by  CLIP-SEGMENTS).  Otherwise,  we  have  completely  finished  with  the  first  profile 
segment  and  can  recurse  after  stripping  it  off.  The  horizon  segments  argument  for  the  recursion  is 
similarly  calculated. 

After  receiving  the  values  letumed  by  the  recursive  call,  we  must  add  to  them  the  pertinent  in¬ 
formation  from  the  section  this  call  handled.  If  CLIP-SEGMENTS  found  a  visible  segment,  it  is 
CONSed  onto  the  list  of  segments  to  draw  returned  by  the  recursive  call;  otherwise,  CLIP  just 
returns  the  result  of  the  recursion.  Because  every  call  to  CUP  is  guaranteed  to  make  some 
progress  to  the  right,  some  horizon  is  generated  for  each  call.  CLIP  calculates  the  new  horizon 
value  by  appending  the  NEW-HORIZON-SEGMENTS  returned  by  CLIP-SEGMENTS  and  the 
new  horizon  returned  by  the  recursive  call. 

One  valid  objection  to  this  algorithm  is  that  it  tends  to  produce  fragmented  horizons.  This  is 
easily  dealt  with  by  making  each  subsegment  point  to  the  segment  from  which  it  was  created. 
Subsegments  that  were  created  from  the  same  segment  are  guaranteed  to  be  collinear  and  hence 
can  be  collapsed  by  OUTER-LOOP-1.  In  one  example,  when  displaying  a  triangulated  digital 
terrain  model  surface,  the  horizon  following  the  clipping  and  display  of  60  profiles  was  a  list 
of  750  segments.  Collapsing  segments  after  each  profile  was  displayed  resulted  in  a  final 
horizon  of  60  segments  and  dramatically  reduced  run  time. 

A  ruce  feature  of  this  algorithm  is  its  ability  to  deal  with  different  segment  representations. 
Only  the  functions  MAKE-SEGMENT  and  CUP-SEGMENTS  need  to  know  how  the  data  are 
structured  and  both  are  straightforward.  Also,  this  algorithm  can  be  generalized  to  finite 
surfaces  by  maintaining  both  top  and  bottom  "horizons." 
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{defun  outer-loop  (profile-list) 

(when  profile-list 

(let*  ( ( initial-horizon-segment 

(make-segment  (make-point  (-  ‘infinity")  (-  ‘infinity*)) 
(make-point  ‘infinity*  (-  ‘infinity*)))) 
(initial-horizon  (list  initial-horizon-segment))) 

(outer-loop-1  profile-list 

initial-horizon) ) ) ) 

(defun  outer-loop-1  (profile-list  horizon) 

(when  profile-list  ;  This  will  terminate  when  we 

;  run  out  of  profiles. 

(multiple-value-bind  (segments-to-draw  new-horizon) 

; ;  CLIP  takes  the  next  profile  on  the  list  and  the  existing 
; ;  horizon  and  returns  SEGMENTS-TO-DRAW  and  the  new  horizon. 

(clip  (car  profile-list) 
horizon) 

(draw-segments  segments-to-draw)  ;  Display  the  segments  on  some 

;  output  device. 

(outer-loop-1  (cdr  profile-list)  ;  Strip  off  the  profile  we’ve  jus 

new-horizon))))  ;  handled 

(defun  clip  (profile-segments  horizon-segments) 

(declare  (values  segments-to-draw  new-horizon-segments ) ) 

(cond  { (null  horizon-segments) 

(error  ‘Ran  out  of  horizon*)) 

{(null  profile-segments) 

; ;  We  have  run  out  of  profile  segments,  so  we  return  a  NIL  to 
; ;  CONS  onto  as  SEGMENTS-TO-DRAW  and  return  the  remaining 
; ;  horizon. 

(values  nil  horizon-segments)) 

{{not  (overlap?  (car  profile-segments)  (car  horizon-segments))) 

; ;  The  first  profile  segment  is  completely  to  the  right  of  the 
; ;  first  horizon  segment 

(multiple- value-bind  (rest -segments-to-draw 

rest-new-horizon-segments ) 

(clip  profile-segments  ;  We  haven't  processed  any, 

;  so  we  pass  through. 

(cdr  horizon-segments))  ;  Strip  off  the  first  one. 

(values  rest -segments-to-draw  ;  Nothing  new  to  draw, 

(cons  (car  horizon-segments)  ;  but  must  return  the 

;  new  horizon  piece 
rest-new-horizon-segments) ) ) ) 

( :else 

; ;  The  left  endpoint  of  the  first  profile  segment  falls  within 
; ;  the  first  horizon  segment. 

(let  ((profile-segment  (car  profile-segments)) 

(horizon-segment  (car  horizon-segments))) 

(multiple-value-bind  (segment -to-draw 

new- hor i zon - s egmen t  s 
remaining-prof ile-segment 
remaining-horizon-segment ) 

(clip-segments  profile-segment  horizon-segment) 

; ;  We  now  have  all  the  information  we  need  for  the  recursive 
; ;  call . 

(multiple-value-bind  (rest -segments -to-draw 

rest-new-horizon-segments) 


(clip 


;;  Calculate  the  PROFILE-SEGMENTS  to  send  down. 

(if  remaining-prof ile-segment  ;  If  some  of  the  profile 

;  segment  wasn't  handled 
(cons  remaining-prof ile-segment 
(cdr  profile-segments)) 

(cdr  profile-segments)) 

; ;  Calculate  the  HORIZON -SEGMENTS  to  send  down 

(if  remaining-horizon-segment  ;  If  some  of  the  horizon 

;  segment  wasn't  handled 
(cons  remaining-horizon-segment 
(cdr  horizon-segments)) 

(cdr  horizon-segments))) 

(values 

; ;  Calculate  the  SEGMENTS-TO-DRAW  to  return. 

(if  segment -to-draw 

(cons  segment -to-draw 

rest-segments-to-draw) 
rest -segments -to-draw) 


Our  contribution. 
Result  of  recursion. 
This  call  contributes 
nothing . 

We  always  contribute 
something  to  th' 
to  the  horizon, 
rest-new-horizon-segments) ))))))) 


(append  new-horizon-segments 


6.3.3.  Rendering 

In  computer  graphics  terminology,  a  scene  is  a  mathematical  represeitation  of  a  picture.  An 
image  is  the  manifestation  of  a  scene  on  a  display  device.  Rendering  is  the  processing  of  turning 
a  scene  into  an  image.  In  standard  computer  graphics  implementations,  a  scene  is  a  collection  of 
2D  polygons  oriented  in  a  3D  space,  with  the  visible  portion  of  each  polygon  calculated  and 
marked  given  a  particular  viewpoint,  plus  a  scene  illumination  function.  An  image  typically 
consists  of  a  collection  of  pixel  intensity  and  color  values  for  a  CRT  display. 

Rendering  a  scene  already  broken  up  into  planar  triangles  or  polygons  is  a  standard  feature  of 
many  workstations  and  window  systems  and  is  oftoi  assisted  by  special  hardware.  All  a 
computer-aided  engineering  system  need  do  is  format  a  list  of  triangles  appropriately  and  let 
the  rendering  program  run  (I  hooked  up  SITE  CONTROLLER  with  two  different  rendering 
programs  in  this  fashion  and  never  sp«it  more  than  one  hour  writing  the  interface) .  This 
approach  has  advantages:  1)  the  CAE  system  programmers  are  not  burdened  with  the  task  of 
reviewing  the  computer  graphics  literature  and  implementing  algorithms,  and  2)  with  an 
abstraction  barrier  between  the  CAE  system  and  the  renderer,  the  CAE  system  safely  benefits 
from  whatever  efficiencies  the  implementors  of  the  renderer  obtained  by  exploiting  special 
hardware  and/or  clever  or  ugly  software. 

Comprehensive  discussions  of  rendering  can  be  found  in  numerous  graphics  textbooks  [Foley  and 
Van  Dam  1982;  Rogers  1985]. 

6.3.4.  Prospective  Surfaces 

Surfaces  that  do  not  exist  in  the  real  world  are  referred  to  by  the  user  interface  as  prospective 
surfaces.  In  fact,  these  are  represented  with  instances  of  exactly  the  same  class  (SURFACE)  as 


50 


surveyed  surfaces.  Prospective  surfaces  are  created  by  sending  a  message  to  an  existing  surveyed 
or  prospective  surface  with  a  boundary  polygon  for  the  new  surface.  This  polygon  is  projected 
onto  the  existing  surface  and  its  vertices,  along  with  "enough"  (see  below)  other  points  to  make 
a  good  seam,  are  given  elevations  interpolated  by  the  existing  surface.  These  points  become  the 
first  surveyed  points  of  the  new  prospective  surface. 

Additional  surveyeo  points  will  be  added  either  by  the  user  explicitly,  by  the  user  sketching 
contour  lines,  or  by  SITE  CONTROLLER  monitoring  earthmoving,  for  example,  in  order  to  reflect 
the  path  of  a  bulldozer's  blade.  Calculating  the  "best"  surface  from  contours  is  a  research 
problem  [Meyers  1992]  and  one  that  I  made  no  attempt  to  solve.  My  code  simply  ?pproximates 
contours  by  surveyed  points  at  regularly-spaced  intervals  and  hopes  that  the  Delaunay 
triangulation  will  result  in  something  reasonable.  The  user  is  free  to  add,  delete  or  move  points 
if  he  doesn't  like  what  he  sees. 

([>ne  of  the  toughest  challenges  here  is  figuring  out  how  many  surveyed  points  to  string  along  the 
boundary  of  the  prospective  surface,  especially  since  the  prosp)ective  surface  is  usually  going  to 
be  sewn  together  with  the  original  surface  at  sonte  point.  What  would  be  particularly  undesir¬ 
able  is  for  elevations  within  the  new  surface  boundary  to  be  interpolated  based  on  surveyed 
points  outside  the  boundary.  This  can  be  prevented  by  ensuring  that  no  triangle  cuts  across  the 
boundary.  A  brute  force  solution  is  just  to  add  points  every  foot  and  expect  that  the  standard 
Delaunay  triangulation  will  not  result  in  any  cross-boundary  triangles.  However,  adding  this 
much  data  might  make  the  system  unacceptably  slow,  especially  on  1  MIPS  Symbolics  machine. 
Thus,  the  method  works  by  adding  a  surveyed  point  wherever  the  new  surface  boundary  cuts  a 
triangulation  edge  of  the  old  surface.  When  surfaces  are  sewn  together,  the  edges  along  the 
bouTKlary  are  added  to  the  list  of  forced  cormections.  Thus,  triangles  do  not  cut  across  the  bound¬ 
aries  and  enough  intermediate  points  have  been  added  that  we  don't  have  a  long  skinny  trian¬ 
gle  along  the  side  of  the '  jundary  polygon.  Figure  6.6  illustrates  the  process  of  defining  a 
prospective  surface  in  detail. 
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Figiire  6.6a  Designing  a  prospective  surface  begins  with  the  specification  of  the 
boundary  seam  (outer  polygon).  Then  the  user  sketches  in  new  ccMitours  for  the  interior, 
which  for  this  building  pad  consist  only  of  a  single  contour  at  105.7'. 


Figure  6.6b  Sewing  together  the  building  pad  with  the  original  surveyed  surface  re- 
quires  ensuring  that  triangulation  never  cuts  across  the  boundary  polygon.  Thus,  eleva- 
tions  inside  the  boundary  are  completely  determiited  by  surveyed  points  inside  the 
boundary  and  elevations  outside  the  boundary  (i.e.  on  the  original  surface)  are  urutf- 
fected  by  the  new  contours.  To  accomplish  this,  the  points  along  the  boundary  are  con¬ 
nected  with  forced  connections  (the  edges  shown  here). 
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Figure  6.6c  Graphically  overlaying  the  new  building  pad  surface  with  the  original 
surveyed  surface,  we  see  that  all  the  "extra  points"  along  the  boundary  polygon  are  po¬ 
sitioned  at  each  intersection  of  the  boundary  polygon  and  the  original  surface's  triangu¬ 
lation  edges. 


Figure  6.6d  Here  is  the  triangulation  of  the  combined  surface.  Note  that,  as  adver- 
tisi^,  no  triangle  cuts  through  the  bovundary  polygon  and  none  of  the  triangles  outside 
tlw  boundary  polygon  are  too  long  or  skinny. 


Figure  6.6e  Contouring  the  finished  surface  reveals  a  large  flat  area  suitable  for 
building.  Note  that  SITE  CONTROLLER  has  calculated  the  overhaul,  i.e.  the  net 
amount  of  earth  that  will  have  to  be  trucked  onto  the  site  to  realize  the  building  pad. 

6.3.5.  Volumetric  Computation  with  Surfaces 

Given  an  actual  and  a  prospective  surface,  it  is  natural  to  ask  questions  about  the  cost  of 
realizing  the  prospective  surface.  How  much  earth  must  be  moved?  What  is  tfie  overhaul,  i.e. 
the  net  amount  of  earth  that  will  have  to  be  brou^t  onto  or  hauled  away  from  the  site?  Can 
the  overhaul  be  reduced  to  zero  simply  by  rrwving  a  building  pad  up  or  down? 

In  computing  the  overiiaul,  one  is  asking  the  size  of  the  faceted  volume  between  two  surfaces. 
This  volume  is  probably  not  ccmvex  or  even  ctmtiguous.  However,  one  need  not  ever  consider  the 
volume  per  se,  but  only  compute  the  height  of  the  surface  above  sea  level.  This  is  done  with 
five  lines  that  loop  through  every  triangle  in  the  surface,  multiplying  the  area  of  the  tri¬ 
angle's  projection  onto  the  x-y  plane  by  the  elevation  of  the  triangle's  centroid  and  summing 
each  product.  If  the  two  surfaces  have  ‘*'e  same  boundary  polygon,  subtraction  is  all  that  re¬ 
mains  to  be  done.  If  the  two  surfaces  are  not  co-extensive  in  the  plane,  the  smaller  one  is  pro¬ 
jected  onto  the  larger  one  and  just  that  piece  of  ttie  larger  one  is  carved  out  for  use  in  die  compu¬ 
tation: 
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(defmethod  ( : volume-between-you-and-larger-surface  surface)  { larger-surface) 
(l®t*  ((other-surface-piece  (send  self  :piece-of -larger-surface-below-self 

larger-surface) ) 

(iry-volume-above-sea- level  (send  self  :voluine-above-sea-level)  ) 
(other-volume  (send  other-surface-piece  : volume-above-sea-level ) ) 

) 

{-  my-volume-above-sea-level  other-volume) ) ) 

(defmethod  ( :piece-of-larger-surface-below-self  surface)  (larger-surface) 
(let*  ( (my-boundary-points  (send  boundary -polygon  :vertices)) 
(projected-boundary-points 

(send  larger-surface  :project-surveyed-points  my-boundary-points)) 
(real -points -inside -project ion 
(send  larger-surface 

rsurveyed-points-within-polygon  boundary -polygon) ) 
(copied-real-points  (loop  for  point  in  real-points-inside-project ion 

collect  (send  point  :copy-self ) ) ) 
(combined-points  (append  projected-boundary-points 

copied-real-points) ) 

(new-surface  (ma)ce- instance  'surface  :n2une 

(format  nil  “Piece  on  -a  below  -a* 
larger-surface  self))) 

) 

(send  new-surface  : set-surveyed-points  combined-points) 
new-surface) ) 


When  determining  the  difficulty  of  a  project,  a  standard  dvil  engineering  drawing  is  tf»e  cut 
and  fill  diagram.  This  shows  the  areas  of  the  site  where  earth  must  be  removed  (cut)  shaded 
differently  from  those  where  earth  must  be  added  (filled).  Again  I  wimped  out,  but  this  time 
by  imposing  a  rectangular  grid  over  the  area  in  question,  asking  each  surface  for  its  elevation  at 
each  grid  vertex  aiKl  then  declaring  that  grid  vertex  to  be  either  cut,  fill,  or  neutral  as  appro¬ 
priate  (see  Figure  6.7). 


Figure  6.7  Cut  and  fill  diagram  for  adding  the  prospective  surface  building  pad  to  the 
or;jinal  surveyed  surface.  Computation  was  performed  on  a  64x64  grid.  Areas  that 
must  be  filled  are  shown  in  black;  those  that  are  to  be  cut  are  shown  in  gray. 
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Representing  terrain  with  a  fixed  rectangular  grid  calls  to  mind  all  the  primitive  limited 
FORTRAN  surface  modelling  systems  of  the  1960's  and  70's.  A  fixed  grid  does  not  satisfy  any  of 
the  desiderata  I've  given  for  a  good  surface  model.  In  particular,  it  cannot  represent  complex 
areas  of  the  site  at  a  finer  level  of  detail  and  it  cannot  reflect  the  topology  of  natural  terrain. 
However,  grids  enormously  simplify  many  algorithms. 

Attacking  the  cut  and  fill  problem  directly  with  the  two  triangulated  surface  models  would  in¬ 
volve  many  nasty  triangle  projections  and  intersections.  A  programmer  might  be  kept  busy  for 
days  working  this  out.  However,  SITE  CONTROLLER  surfaces  already  have  a  method  for 
interpolating  the  elevation  at  arbitrary  points.  Using  this  method  to  calculate  elevations  at 
grid  points  for  both  the  hypothetical  and  actual  grids  requires  less  than  50  lines  of  code.  The 
resultant  two  grids  can  be  compared  trivially.  If  the  hypothetical  grid  is  higher  than  the 
actual  grid  at  one  point,  that  point  is  colored  black  for  fill;  if  lower,  gray  for  cut;  if  nearly 
equal,  white  for  neither  cut  nor  fill. 

Although  one  might  argue  that  this  approach  is  inaccurate,  consider  the  fact  that  output  de¬ 
vices  only  have  so  much  resolution.  Once  the  grid  is  fine  enough  so  that  each  pixel  is  covered  by 
a  single  grid  vertex,  no  better  diagram  can  be  produced.  Producing  this  elaborate  intermediate 
data  structure,  i.e.,  the  grid,  and  then  d\rowing  it  away  seems  computationally  wasteful,  but  if 
this  approach  is  fast  enough  to  satisfy  the  user,  spending  extra  programmer  days  or  weeks  on  a 
more  elegant  algorithm  is  pointless. 

In  general,  many  problems  lend  themselves  naturally  to  gridded  solutions.  Before  tackling  a 
difficult  computational  geometry  problem  with  triangulated  surfaces,  it  is  often  worth  asking 
if  a  straightforward  method  using  grids  might  not  work  just  as  well. 

6.3.6.  Intervisibility 

A  comprehensive  intervisibility  algorithm  answers  the  following  questions:  (military)  Could 
an  enemy  on  that  hill  see  a  tank  dug  in  behind  this  ridge?  (urban  planning)  Could  the  occupant 
of  a  third  floor  bedroom  in  this  house  see  the  city  dump?  (architecture)  What  kind  of  light 
would  this  basement  room  get?  (town  council)  How  many  people  in  this  condo  development 
could  see  the  red  light  district  from  their  balconies? 

Point-to-point  intervisibility  questions  are  easily  answered  by  intersecting  a  query  line  from  pi 
to  p2  with  the  surface.  Given  a  piecewise-planar  surface  model,  an  efficient  algoridim  com¬ 
putes  the  intersection  of  the  planar  projection  of  the  query  line  with  the  model's  triangle  edges. 
If  the  elevation  of  any  edge  at  the  intersection  point  is  higher  than  the  line,  then  there  is  no  in¬ 
tervisibility.  If  the  query  line  is  higher  than  each  edge  at  its  intersection  points,  then  the 
view  from  pi  to  p2  is  unobstructed.  (Note:  we  can  safely  ignore  data  within  tire  triangles  be¬ 
cause  we  assume  a  pif-cewise-planar  surface  model  and  therefore  the  extremes  must  occur  at 
edges.) 

I  implemented  the  preceding  point-to-point  intervisibility  algorithm  as  a  method  of  the  class 
SURFACE,  but  could  not  think  of  an  efficient  solution  to  overall  intervisibility  problems. 
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Recently,  I  uncovered  a  large  body  of  work  that  has  beoi  done  in  the  area  of  shadow  generation 
for  computer  graphics  [Woo  1990].  Shadow  generation  asks  the  question  "Which  parts  of  the 
surface  are  hidden  from  the  light  source?"  If  one  positions  the  light  source  at  a  potential 
viewer's  location,  then  the  same  algorithm  answers  the  question  "Which  parts  of  the  surface 
are  invisible  to  the  viewer?" 

Shadow  generation  algorithms  that  are  useful  crutches  for  intervisibility  calculations  are  pri¬ 
marily  ones  that  postulate  a  static  world  and  movable  light  sources.  A  good  example  of  the 
genre  is  in  [Chin  and  Feiner  1989]  where  a  Shadow  Volume  Binary  Space  Partitioning  tree  is 
used  to  organize  polygonal  terrain  elemotts  so  that  shadows  can  be  computed  in  0(n)  tinw. 
Each  polygon  must  be  examined  once,  but  its  interactions  with  all  the  other  polygons  need  not  be 
considered. 


6.3.7.  Convex  Hull 

An  implementation  of  Graham's  scan  determines  the  convex  hull  of  a  set  of  points  in  the  plane. 
(Remember  that  a  convex  hull  is  li'c;  smallest  convex  polygon  that  contains  a  set  of  points  in  the 
plane — shaped  like  a  rubber  bard  rretched  around  a  bunch  of  pins,  as  in  Figure  6.1.)  In 
particular,  this  algorithm  works  <n  0(n  log/t)  time  on  any  set  of  points  that  have  methods  to 
handle  messages  such  as  :2D-DISTANCE  and  :2D-ANGLE  to  other  points.  The  algorithm  nms 
as  follows: 

1.  Find  an  internal  location  q  (this  can  be  done  by  taking  the  centroid  of  any  three 
points  in  the  set  S) 

2.  Sort  the  points  of  S  by  polar  angle  and  distance  from  q  and  arrange  them  into  a  circu¬ 
lar  doubly-linked  list,  with  START  equal  to  the  rightmost,  smallest  y  coordinate  point 
(certainly  a  hull  vertex). 

3.  Repeatedly  examine  triples  of  consecutive  points  in  counter<lockwise  order.  If 
PiPiPi  forms  an  angle  of  greater  than  180°,  call  it  a  "right  turn"  aiKl  throw  out  the 
middle  point  from  consideration  because  it  must  be  an  interior  point;  now  back  up  and 
consider  the  angle  formed  by  p^p^py  If  P1P2P3  forms  a  "left  turn,"  declare  ttie  first 
point  to  be  part  of  the  hull  and  advance  the  scan  to  consider  the  next  three  points 

iPiPiP*)- 

4.  Stop  when  we  get  back  to  the  START. 
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The  implementation  of  Graham's  Scan  is  listed  below  in  order  to  illustrate  the  compactness  of 
Lisp  in  specifying  computational  geometry  algorithms. 

(defun  grahaun-hull  (point-set-1) 

(let*  ((point-set  (copy-list  point-set-1)) 

(internal-point  (find-internal-point  point-set)) 

( sorted-points 

( sort -about -point  internal-point  point-set)) 

(circular-list  (make-circular-list  sorted-points)) 
(starting-point  (find-starting-point  (aref  circular- list  0)))) 
(loop  with  vertex  =  starting-point 

; ;  these  will  be  updated  with  every  iteration 
for  next  =  (send  vertex  : next -element ) 
for  next-next  =  (send  next  :next-element ) 
with  have-we-ever-advanced-beyond-start?  =  nil 
;;  we  stop  when  we've  once  gotten  beyond  the  start 
; ;  but  we  are  now  back  there 

until  (and  have-we-ever-advanced-beyond-start? 

(eq  next  starting-point)) 
do 

(cond  ((left-turn?  vertex  next  next-next) 

(when  (and  (not  have-we-ever-advanced-beyond-start? ) 

(eq  vertex  starting-point)) 

; ;  we're  at  the  starting  point  and  about  to  advance 
(setq  have-we-ever-advanced-beyond-start?  t)) 

(setq  vertex  next)) 

( :else 

(send  next  :delete-self ) 

(setq  vertex  (send  vertex  rprevious-element ) ) 

)  )  ) 

(send  starting-point  :collect-all-values) 

)  ) 

Note  that  the  code  is  greatly  simplified  by  the  ability  of  the  points  to  take  care  of  themselves. 
For  example,  this  program  only  has  to  refer  to  the  circular  list  once  when  getting  the  starting 
point.  After  that,  navigation  through  and  modification  of  the  data  structure  is  performed  by 
sending  messages  to  points  in  the  data  structure.  For  a  fuller  explanation  of  the  algorithm,  al¬ 
beit  with  a  serious  error  (corrected  in  the  preceding  code  fragment),  see  [Preparata  and  Shamos 
1985].  The  original  algorithm  description  may  be  found  in  [Graham  1972). 

6.3.8.  Hydrology 

The  study  of  water  flow  on  and  below  the  surface  of  a  site  is  called  hydrology.  Surface  water 
can  do  tremendous  damage  to  earthworks  and  structures;  groundwater  can  carry  toxins  to  remote 
locations  in  unexpected  ways.  Thus,  hydrolt^  is  one  of  the  most  important  kinds  of  analysis  to 
support.  I  implemented  some  very  primitive  hydrology  code  that  fails  miserably  due  to  a 
combination  of  rwivet6  and  the  piecewise-planar  nature  of  the  default  surface  model.  Points 
are  declared  to  be  peaks  if  diey  are  higher  than  all  the  points  to  which  they  are  connected; 
points  are  pits  if  all  their  neigjibors  are  higher.  For  each  edge  in  the  triangulation,  the  code 
calculates  the  gradient,  i.e.,  direction  of  fastest  ascent,  for  botfi  adjacent  triangles.  Next,  the 
cross  product  of  the  projection  of  the  edge  in  the  x-y  plane  is  computed  with  both  gradients.  If 
the  cross  products  have  z  components  with  different  signs,  the  gradients  either  botfi  point  in 
and  the  edge  is  part  of  a  ridge,  or  both  point  out  and  the  edge  is  part  of  a  stream. 
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Intuitively,  these  local  methods  should  produce  a  nice  global  map,  with  peaks,  passes  and  pits 
marked  amidst  a  collection  of  streanis  and  ridges  that  would  naturally  lead  a  human  to  see  the 
drainage  basins.  What  happei\s  in  practice  is  that  water  flows  in  sheets  across  these  planar 
triangles  and  the  ridges  and  streams  are  discontinuous,  as  shown  in  Figure  6.8. 


Figure  6,8  Hydrology  map  computed  simplistically  on  a  C®  piecewise-planar  surface. 
Note  that  the  ridges  (thin  dashed  lines)  and  streams  (thick  dashed  lines)  do  not  form 
coherent  networks.  This  is  a  consequence  of  orJy  triangvilation  edges  being  ridge  or 
stream  candidates.  Points  are  classified  as  peaks  (K),  pits  (T),  or  passes  (P). 

I  am  currently  considering  ways  to  compute  better  hydrology  maps  either  from  the  surface 
model  or  by  using  more  clever  algorithms  on  the  piecewise-planar  surfaces. 

6.3.9.  Traditional  CAD  subsystem 

Althou^  a  computer-aided  engineering  system  is  superior  to  traditional  computer-aided 
design  (CAD)  systems  in  it,  knowledge  of  what  is  being  modelled,  and  hence  in  its  ability  to 
support  analysis,  sometimes  one  simply  wants  to  sketch  a  picture  or  add  a  piece  of  text  to  a 
drawing.  SITE  CONTROLLER  supports  this  via  geometry  bags,  which  are  simply  collections  of 
graphical  entities  about  which  the  system  knows  nothing.  This  is  just  what  a  traditional  CAD 
system  gives  the  user,  although  SITE  CONTROLLER  provides  a  tree-structured  hierarchy  of 
named  geometry  bags  where  CAD  systems  normally  offer  only  a  flat  choice  of  numbered  layers. 

Currently,  the  only  graphical  entities  implemented  are  text,  segments,  splines  and  circular  arcs. 
Text  can  be  in  any  size  and  orientation  from  any  vector  font  (see  §6.3.20).  The  CAD  system  snaps 
most  mouse  clicks  to  nearby  "significant  points"  of  existing  graphical  aitities  (e.g.,  a  user  who 
starts  a  new  line  segment  3  pixels  from  an  endpoint  of  a  circular  arc  will  find  toat  the  segment 
starting  point  has  been  snapped  to  the  circular  arc  endpoint — if  he  doesn't  like  this,  he  can 
always  zoom  in  and  work  at  a  finer  resolution). 
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6.3.10.  FRAME  code 


The  Lisp  Machine  window  system  thinks  of  the  world  as  consisting  of  one  or  more  screer«.  On 
each  screen  is  a  single  frame.  A  frame  is  a  large  window  that  breaks  up  the  screen  for  its  panes, 
which  are  daughter  windows.  None  of  these  panes  overlap  and  the  amount  of  space  each  occu¬ 
pies  is  determined  by  applying  a  series  of  constraints  to  the  screen  size.  Thus,  the  frame  is  usu¬ 
ally  referred  to  as  a  constraint  frame. 

SITE  controller's  primary  constraint  frame  is  the  center  for  user  interface  and,  after 
establishing  itself  on  the  main  screen,  grabs  control  of  any  other  screens  (typically  color). 
Keyboard  commands  all  go  to  this  frame  arul  include  comnruinds  for  printing  help,  undoing  recent 
actions,  saving  data  structures  out  to  files,  loading  files,  accessing  utility  functions,  changing 
the  configuration  of  the  frame,  and  resetting  the  system. 

All  the  panes  (subwindows)  in  this  frame  inherit  from  the  class  LAND-HACKER-PANE, 
which  has  methods  to  forward  user  interface  messages,  process  mouse  clicks  in  a  uniform  way, 
and  pick  an  appropriate  sibling  pane  for  interaction  with  the  user.  The  most  important  panes 
are  ii^staiKes  of  the  class  SITE-VIEW-PANE,  which  combines  basic  surface  and  site  viewing 
classes  with  specialized  capabilities  from  such  classes  as  MINE-VIEW-MIXIN.  As  a  diehard 
believer  in  the  modeless  religion  of  EMACS  and  the  Macintosh,  one  of  my  saddest  days 
implementing  SITE  CONTROLLER  was  tfte  day  I  added  a  command  to  this  class  that  lets  the 
user  select  among  six  modes: 

•  standard  CAE  (surface  definition  and  volumetric  calculation) 

•  actor  simulation  (planning  excavation — see  §63) 

•  logistics  (an  extension  of  SITE  CONTROLLER  to  help  the  U.S.  Army  lay  out  field 

ammunition  dumps — not  described  in  this  report) 

•  location  system  simulation  (another  undescribed  extension  built  to  aid  development  of 

a  radio  frequency  location  system) 

•  real-time  vehicle  control  (monitoring  and  assisting  earthmoving — see  §6.6) 

•  mine  planning  (figuring  out  where  to  send  a  dragline  to  expose  coal  seams — see  §6.4). 

Despite  my  aversion  to  modes,  I  concluded  that  there  was  simply  no  way  to  fit  all  the  possible 
commands  into  the  mouse  command  datastructure  without  both  running  out  of  shift  keys  and 
hopelessly  cluttering  the  user  interface. 

Statistics  panes  are  available  to  show  results  of  computations  or  dynamic  information  as  the 
user  moves  the  mouse.  Packet  display  panes  graphically  display  communications  witfi  vehi¬ 
cles.  Perspective  views  show  views  from  arbitrary  positions  of  site  surfaces  or  a  display,  up¬ 
dated  in  real  time,  of  d\e  view  from  a  vehicle.  Bar  graph  and  semicircular  gauges  are  avail¬ 
able  to  display  vehicle  performance  and  loads  on  implements.  A  special  zoning  law  database 
editor  window  is  available  as  well  as  a  vector  font  editing  utility  pane. 
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Overall,  17  panes  appear  in  different  combinations  and  relative  positions  on  the  main  screen  in 
a  total  of  10  separate  configurations.  Color  screer\s  may  have  either  one  large  or  four  small  site 
view  panes  visible  at  once. 

6.3.11.  Site  Data  Structure 

As  with  surfaces,  the  class  definition,  database  storage  and  user  interface  code  for  site  data 
structures  are  all  automatically  generated  from  one  big  list.  Site  instances  contain  information 
on  the  name  of  the  site,  the  customer  who  is  interested  in  the  site,  the  size  and  political 
location  of  the  site,  parameters  for  surface  visualization,  data  structures  for  managing  surfaces, 
data  structures  for  managing  lot  boundaries,  a  list  of  geometry  bags  for  miscellaneous 
annotations,  a  quad  tree  organizing  site  features  that  are  not  properly  associated  with  any 
surface,  a  graph  of  roads  on  the  site,  and  a  list  of  utility  lines  running  through  the  site. 

Methods  of  the  class  SITE  mostly  have  to  do  with  maintaining  a  site's  data  structures  and  pro¬ 
viding  a  user  interface  for  both  data  structure  inspection  and  manipulation.  Very  little  analy¬ 
sis  is  done  by  methods  of  SITE. 

6.3.12.  Site  Feature  Quadtree 

Many  features  in  a  site  may  be  modelled  formally  and  geometrically  but  do  not  properly  belong 
to  any  single  surface.  Examples  of  such  features  include  bodies  of  water,  barrels  of  hazardous' 
waste,  groves  of  trees,  arKl  buildings.  These  must  be  modelled  formally  to  permit  aruilysis,  i.e., 
a  grove  of  trees  should  be  represented  as  an  instarvre  of  TREE-GROVE  rather  than  as  a  bunch  of 
lines  in  a  geometry  bag.  On  a  large  site  that  is  modelled  in  detail  with  many  features  it  would 
be  nice  to  know  which  features  we  must  consider  when  working  in  a  particular  location. 

The  Site  Feature  Quadtree  organizes  the  site  features  so  as  to  permit  relevant  features  to  be  lo¬ 
cated  in  0(logn)  time,  where  n  is  the  number  of  features.  A  quadtree  is  a  tree  where  every 
node  that  is  not  a  leaf  has  four  children.  Each  node  claims  a  rectangle  of  space  in  the  plane  and 
it  divides  that  space  among  its  children  by  splitting  the  rectangle  with  uvo  lines,  usually 
equally  so  that  each  child  gets  one  fourth  of  the  space  (see  Figure  6.9).  A  rectangle  of  space 
encompassing  the  entire  site  is  allocated  to  the  root  node.  When  trying  to  And  the  leaf  that 
surrounds  a  query  point,  one  need  only  start  at  the  root  and  ask  two  questions:  Is  the  query  point 
to  the  left  of  the  vertical  splitting  line?  Is  the  query  point  below  the  horizontal  splitting  line? 
The  answers  to  those  two  questions  direct  the  search  to  one  of  the  four  children  and  each  0(1) 
comparison  results  in  three  fourths  of  the  search  space  being  eliminated,  thus  resulting  in 
O(logn)  for  the  complete  search. 
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Figure  6.9  Sample  quadtree.  Note  that  different  areas  of  the  site  are  represented  at 
different  levels  of  detail. 

Every  site  feature  contains  an  area  of  interaction,  represented  either  as  a  circle  or  a  polygon. 
Any  query  point  within  the  area  of  interaction  may  theoretically  by  affected  in  some  way  by 
the  site  feature.  For  example,  the  area  of  interaction  for  a  poiui  might  he  the  area  flooded  by 
the  pond  during  a  100  year  storm.  A  site  feature  is  stored  at  the  smallest  quadtree  node  that 
completely  contains  its  area  of  interaction.  Thus,  a  very  large  feature  mi^t  be  stored  at  the 
root  node  (or  even  a  small  feature  that  happened  to  overlap  a  splitting  line). 

Finding  all  the  site  features  that  might  affect  a  query  point  is  as  simple  as  traversing  the 
quadtree  to  the  smallest  containing  leaf  node,  coUecting  all  the  site  features  on  the  way  down. 

If  too  many  site  features  congregate  at  nodes  too  high  up  in  the  tree,  tt>ere  are  standard  algo- 
rittuns  for  choosing  splitting  lines  so  that  the  data  are  distributed  better  (Samet  1984]. 
However,  I  never  implemented  any  optimizations  because  I  never  encountered  a  site  where  even 
linear  search  would  have  been  a  problem. 

6.3.13.  Surface  Model 

SITE  controller's  standard  triangulation  of  points  of  known  elevation  may  be  employed  to 
generated  and  models,  i.e.  surface  riKxlels  ccwitinuous  through  the  first  and  second 
derivatives.  Imagine  that  each  triangle  is  a  pateh  of  a  surface  whose  elevation  is  determined 
by  a  polynomial  with  nine  or  more  terms.  Different  coefficients  are  selected  for  each  triangle 
and  ttius  each  triangle  is  a  patch  of  a  different  continuous  surface.  It  is  possible  to  set  tt>e 
coefficients  such  that  first  and  eva\  second  derivatives  are  continuous  across  the  triangle  edges, 
i.e.  the  boundaries  between  the  patches.  The  resulting  surface  is  much  smoother  than  a 
piecewise-planar  surface,  but  not  necessarily  more  accurate  (ttus  is  why  SITE  CONTROLLER 
does  not  waste  precious  Lisp  Machine  cycles  computing  everything  with  smooth  surfaces). 
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Continuity  issues  are  of  tremendous  importaiKe  to  airplane  and  automobile  designers.  Whether 
a  surface  is  or  may  affect  the  aerodynamics,  ease  of  fabrication,  and  visual  appeal.  A 
model,  where  the  second  derivative  is  everywhere  continuous,  might  at  first  be  thought 
superior  in  every  case.  However,  curve  fitting  polynomials  tend  to  behave  perversely. 
Restrictions  in  one  region  result  in  absurd  oscillations  and  bulges  in  other  areas.  Further 
complicating  matters  is  the  current  vogue  in  surfaces,  where  the  direction  of  the  gradient 
remains  constant  across  patch  boundaries,  but  the  magnitude  need  not.  By  relaxing  the 
restriction  that  continuity  be  maintained  for  magnitude,  the  surface  oscillates  less  while 
appearing  just  as  smooth  to  the  human  eye. 

Fortunately  for  computer-aided  civil  engineering  programmers,  a  bulldozer  is  not  exactly  a  pre¬ 
cision  instrument  Continuous  surface  models  are  useful  mainly  for  drawing  smooth  contour  maps 
that  please  the  user's  eye  and  when  performing  certain  kinds  of  computation  that  degenerate  on 
a  C®  surface. 

There  is  a  tremendous  body  of  literature  on  surface  modelling,  reflecting  the  fact  that  an  infi¬ 
nite  variety  of  polynomials  that  will  fit  any  given  data  set.  Most  of  the  methods  aim  to  mini- 
rruze  a  metric  of  "peculiarity,"  such  as  oscillation,  torsion  or  tension.  For  example,  consider  toi 
points  in  a  horizonal  line  in  the  plane,  e.g.  (0,1),  (1,1),  (2,1),  etc.  A  15th-order  polynomial  that 
went  through  all  ten  points,  but  did  so  by  oscillating  between  -100  and  -t-lOO  would  not  be 
considered  by  most  people  to  be  as  good  a  fit  as  a  15th-order  polynomial  that  looked  more  or 
less  like  a  horizontal  line. 

An  interesting  illustration  of  the  dramatic  changes  that  can  be  wrought  in  an  interpolated 
surface  merely  by  changing  a  teitsion  parzuneter  can  be  found  in  [Montefusco  arul  Casciola  1989]. 

A  conference  symposium  (Rice  1977]  contains  a  wealth  of  classic  papers,  including  a  formal 
justification  for  choosing  particular  triangulations  by  C.L.  Lawson,  a  survey  of  surface 
modelling  with  an  emphasis  on  triangle-based  interpolations  of  irregularly  spaced  data  by 
Robert  E.  Barnhill,  and  an  attempt  to  automatically  compensate  for  incompatibilities  among 
floating-point  implementations  by  W.S.  Brown. 

Sm<X)th  contouring  in  SITE  CONTROLLER  is  performed  using  a  good  basic  algorithm  described 
in  [Nielson  1980].  Each  triangle  has  a  different  nine-parameter  polynomial.  First  derivative 
continuity  is  accomplished  by  ensuring  that  interpolated  elevations  very  close  to  a  triangle 
edge  are  almost  entirely  determined  by  the  elevations  of  the  two  endpoints  of  that  edge,  i.e., 
elevation  data  from  the  "third"  point  of  each  triangle  does  not  contribute  to  interpolations 
along  the  opposite  edge. 

A  new  data  structure  is  created  to  support  Nielson's  interpolant,  an  INTERPOLATING- 
TRIANGLE,  which  inherits  from  the  basic  TRIANGLE  class  but  adds  a  cache  for  15  interpolant 
parameter  values  and  a  list  of  child  triangles.  The  child  triangles  are  used  for  contouring  and 
rendering.  Rather  than  write  software  to  calculate  the  intersection  of  a  contouring  plane  and  a 
nine  parameter  polynomial  surface,  then  scan  convert  that  intersection  curve  into  pixels,  a  grid 
of  subtriangles  is  imposed  on  each  interpolating  triangle.  The  interpolant  is  used  to  calculate 
tlie  elevation  of  each  subtriangle  vertex  and  piecewise-planar  interpolation  is  used  from  that 
point  on  to  generate  piecewise-iinear  contour  lines.  By  making  the  subtriangle  grid  fine  enough, 
any  desired  degree  of  smoothrwss  may  be  achieved  up  to  the  maximum  resolution  of  the 
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Figure  6.11  Each  triangle  in  the  original  piecewise-planar  triangulation  becomes  an 
INTERPOLATING  TRIANGLE  and  calculates  a  polynomial  surface  patch.  Each  large 
triangle  creates  a  regular  grid  of  subtriangles  and  determines  the  elevation  of  each  ver¬ 
tex  in  the  fine  grid  with  the  polynomial  interpolant.  Contouring  is  done  on  the  piece- 
wise-planar  model  defined  by  ^e  subtrianp' ;  grid. 
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6.3.14.  Drawing  a  Scale 


As  is  so  often  the  case  in  software  development,  problems  that  one  thinks  will  be  very 
challenging  turn  out  to  have  simple  solutions.  Conversely,  problems  that  should  be  trivial  re¬ 
quire  100  lines  of  ugly  code  that  takes  days  to  write.  A  good  example  of  this  situation  is  the 
software  that  draws  a  scale  on  a  map  of  the  site,  i.e.  one  of  those  blocks  of  alternating  black  and 
white  rectangles  with  a  "1:1000"  label  on  top.  Figure  6.14  shows  a  typical  SITE  CONTROLLER 
view  with  a  scale. 


Fig\ure  6.14  View  containing  a  scale — the  contours  are  the  topography  of  a  coal  mine 
plus  rrarkers  for  locations  where  boring  samples  have  been  taken. 
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Probably  the  best  way  to  see  just  how  ugly  this  problem  was  is  to  examine  a  piece  of  the  code: 

(defmethod  (: draw- self  map-scale)  (center -x  center-y) 

(multiple-value-bind  (extent  number-gross-divisions 

extent-per-division  five-or-ten) 

(send  self  ; calculate-scale-parameters ) 

(let*  ( (text-height-above-scale-in-pixels 

(■•■  (send  self  : scale-rectangle-height )  10)) 

(text -height -be low- scale- in -pixels 
(>  (send  self  : scale-rectangle-height )  10)) 

( text -height -above-scale  (send  map  : scale-dimensions-inverse 

text-height-above-scale-in-pixels ) ) 
( text -height-oelow-scale  (send  map  : scale-dimens  ions -inverse 

text -height -below-scale- in-pixels ) ) 
(scale-height  (send  map  :scale-dimensions-inverse 

(*  2  (send  self  : scale-rectangle-height ))) ) 
(height-to-be-erased  {+  text-height-above-scale 

text -height-below-scale  scale-height) ) 

(bloat-width-pixels  12) 

(bloat -width  (send  map  : scale-dimens ions -inverse 

bloat-width-pixels) ) 

(width-to-be-erased  (+  (*2  bloat-width)  extent 

extent-per-division) ) 

(text -center-y  {■*■  center-y  text-height-above-scale)) 

) 

(send  map  : show-rectangle  width-to-be-erased  height-to-be-erased 
(-  center-x  extent-per-division  bloat-width) 

(+  center-y  (*  1.5  text-height-above-scale  ))  :erase) 

(loop  for  i  from  -1  to  5 

for  draw-x  first  (-  center-x  extent-per-division) 
then  (+  draw-x  extent-per-division) 
do 

(send  map  : show-centered-string 

(format  nil  "-d*  (if  (eq  five-or-ten  :five) 

(abs  i) 

(*  2  (abs  i))))  draw-x  text-center-y) ) 

(send  map  : show-centered-string 

(format  nil  "-a  1  division  =  -6f  meters* 

(send  self  ;string-description-of-scale) 
extent-per-division) 

(+  center-x  (*  2  extent-per-division)) 

(-  center-y  text-height -below-scale) ) 

(multiple-value-bind  (wcenter-x  wcenter-y) 

(send  map  :p-to-w  center-x  center-y) 

(send  self  : draw-rectangles  wcenter-x  wcenter-y  extent 
number-gross -divisions  extent-per-division) ) ) ) ) 

It  is  well  to  keep  in  mind  tfiat  not  only  does  the  code  included  here  require  numerous  helper 
procedures,  but  that  it  does  not  even  do  any  of  the  rectangle  drawing. 

6.3.15.  Ruler 

If  d\e  user  wants  to  measure  something  on  the  site,  a  scale  can  be  helpful,  but  a  mouse- 
manipulable  ruler  lets  him  see  exactly  how  far  apart  two  points  are  and  the  angle  between 
them.  When  ruler  measurement  is  selected,  SITE  CONTROLLER  goes  into  a  modal  state  where 
moving  tfie  mouse  moves  the  ruler  and  moving  the  mouse  with  a  button  held  extends  or  rotates 
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the  ruler.  This  code  defines  four  unnamed  procedures,  each  containing  a  lexical  reference  to  the 
recently  created  ruler  object .  These  procedures  are  organized  into  a  matrix  and  passed  down  to 
the  generic  mouse  handler  defined  in  the  PHILG  system.  Here  then  is  an  example  oi  higher- 
order  procedures  at  their  best  when  constructing  user  interfaces: 

(defmechod  ( :generate-ruler  ruler-mixin) 

(Scoptional  ruler-start  ruler-end  window-to-display ) 

(unless  (and  ruler-start  ruler-end) 

(multiple-value  (ruler-start  ruler-end) 

(send  self  : initial-ruler-position) ) ) 

(let*  ((ruler  (make-ruler  ruler-start  ruler-end 

self  window-to-display) ) 

(move  ( Icimbda  (wdx  wdy) 

(multiple-value-bind  (pdx  pdy) 

(send  self  : scale-dimensions-inverse  wdx  wdy) 

(send  ruler  rtranslate  pdx  (-  pdy))))) 

(rotate  (lambda  (wdx  ignore) 

(send  ruler  ; rotate  (/  wdx  80.0)))) 

(extend-left  ( launbda  (wdx  ignore) 

(let  ((pdx  (send  self  : scale-dimensions-inverse  wdx))) 
(send  ruler  :extend-end  (-  pdx))))) 

(extend-right  (lambda  (wdx  ignore) 

(let  ((pdx  (send  self  : scale-dimensions-inverse 

wdx) ) ) 

(send  ruler  : extend-start  pdx)))) 

(operation-matrix  (make-array  '{2  2  2  2))) 

(first-entry 

(list  move  extend-left  rotate  extend-right 

"No  buttons;  drag  L:  extend  left  M:  rotate  R:  extend  right*))) 
(setf  (aref  operation-matrix  0000)  first-entry) 

(send  self  ; generic-mouse-handler  operation-matrix) 

(send  ruler  :kill) 

)  ) 


6.3.16.  Undo  System 

Every  time  an  undoable  operation  is  performed,  a  object  of  the  class  UNDO-SPECIFICATION  is 
pushed  onto  a  list  by  the  user  interface.  The  facility  is  very  simple  because  all  the  information 
about  how  to  do  something  is  encapsulated  in  a  procedure  stored  in  an  instance  variable  of  the 
undo  specification  object.  The  object  also  contains  a  description  of  the  operation  to  fit  into  the 

sentences  "Undo _ T'  and  "Redo _ ?"  and  a  toggle  flag  that  indicates  whether  the  operation 

is  to  be  undone  or  redone.  Multiple  undo  is  supported  by  moving  down  the  list. 

6.3.17.  Lot  Boundaries 

When  a  civil  engineer  is  subdividing  a  large  tract  of  land  into  numerous  lots  for  houses,  the 
customer's  main  goal  is  to  squeeze  as  many  houses  into  the  tract  as  is  legally  possible. 
Furthermore,  road  design  within  the  subdivision  is  intimately  intertwined  with  the  lot  layout. 
SITE  CONTROLLER  provides  a  primitive  facility  for  modelling  and  changing  lot  layouts. 

The  only  classes  are  LOT-BOUNDARY-END-POINT  and  LOT-BOUNDARY,  and  instances  of 
the  two  are  cormected  together  via  instance  variables  to  form  a  doubly-linked  list.  Provision  is 
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made  for  lot  boundaries  that  are  splines  or  circular  arcs,  but  only  lirw  segments  have  been  im¬ 
plemented.  SITE-VIEW-MIXIN  contains  some  rudimentary  methods  that  allow  the  user  to 
slcetch  in  a  lot  layout,  move  lot  boundary  end  points,  and  calculate  lot  areas. 

I  have  not  implemented  the  linkage  among  the  zoning  law  database,  road  modelling  datastruc- 
tures,  and  lot  boundary  data  structures  that  would  have  made  zoning  law  compliance  analysis 
possible. 

6.3.18.  Zoning  Law  Tree 

The  young  man  knoios  the  rules,  but  the  old  man  knows  the  exceptions.  —  Oliver 
Wendell  Holmes 

A  tree  editor  substrate  allows  a  window  to  graphically  display  tree  data  structures, 
automatically  makes  nodes  mouse-sensitive,  lets  the  user  navigate  the  tree,  and  provides 
mechanisms  for  user  editing  of  both  tree  structure  and  data  associated  with  nodes.  The  tree  edi¬ 
tor  is  capable  of  manipulating  all  trees  whose  nodes  are  able  to  respond  to  a  small  set  of  mes¬ 
sages,  e.g.  iPARENT,  CHILDREN,  -.DRAW-SELF,  :HIGHLIGHT-SELF.  In  practice,  all  the 
trees  in  SITE  CONTROLLER  use  nodes  that  inherit  from  the  classes  BASIC-NODE,  which  con¬ 
tributes  instance  variables  and  methods  for  the  basic  data  structure,  and  DISPLAY-NODE- 
MIXIN,  which  contributes  instance  variables  and  methods  for  positioning  and  displaying  nodes 
recursively  on  the  screen. 

Using  the  basic  classes  described  above,  zoning  laws  are  represented  by  a  tree  of  political 
entities  with  authority  over  particular  tracts  of  land,  associating  with  each  node  rules  such  as 
mmimum  lot  area,  minimum  septic  sefoack,  minimum  frontage,  and  whether  frontages  may  be 
sununed  on  a  comer  lot  (Figure  6.15). 
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Figure  6.15  SITE  CC^TROLLER  configured  for  editing  the  zoning  law  database  for 
Europe. 

Each  rule  in  the  zoning  law  database  is  specified  by  a  macro  invocation  of  the  following  form: 
(make-lot -pareuneters-mixin-spec  minimum- lot -area  -infinity  t  :number) 

This  says  that  each  node  shall  hold  a  statutory  minimum  lot  area,  that  the  default  value 
shall  be  minus  infinity,  that  the  value  is  user-settable,  and  that  the  user  interface  software 
should  ensure  that  any  new  value  is  a  number.  This  specification  relies  on  the  default  method 
for  combirung  values  from  different  tuxles,  which  is  to  collect  all  the  values  from  a  node  and  its 
ancestors  into  a  list,  then  choose  the  maximum  from  the  list.  What  allegedly  distinguishes  an 
expert  system  from  a  mere  program  is  that  the  expert  system  can  generate  a  human-readable 
justification  for  its  conclusions.  Thus,  the  zoning  law  node  class  incorporates  a  mechanism  to 
explain  which  political  entity  is  the  limiting  orte  when  responding  to  a  query  about  a 
requirement. 

6.3.19.  Utility  Lines 

Utility  lines  are  represent  as  objects  with  a  description  of  the  contents  of  the  line,  the  diameter 
of  the  pipe,  and  a  3D  path  of  line  segmoits  and  circular  arcs.  Utility  lines  can  draw  themselves 
in  site  views.  I  never  in^lemented  the  real-time  interference  checking  software  diat  would  be 
nice  for  controlling  earthmoving  equipment  (especially  in  light  of  the  number  of  backhoe 
operators  who  are  killed  each  year  when  they  accidentally  strike  gas  lines). 

6.3.20.  Vector  Fonts 


Because  the  Lisp  Machine  window  system  only  supported  bit-mapped  fonts,  which  are  not 
drawable  in  arbitrary  orientations,  I  implemented  code  for  defining  and  displaying  vector  font 
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characters.  A  vector  font  object  contaizu  the  following;  the  font  name,  a  hash  table  mapping 
strings  to  vector  font  characters,  and  a  default  bounding  box  that  guides  the  user  in  defining  new 
characters  that  are  about  the  same  size  as  all  the  others  in  a  font.  Note  that  strings,  not  ASCII 
characters,  are  mapped  to  vector  font  characters.  Thus,  descriptive  names  for  characters  are 
possible  such  as  "bulldozer"  or  "brick  depot". 

The  vector  font  editor  is  a  mode  of  the  SITE  CONTROLLER  system  wherein  the  user  is  able  to 
add  r\ew  characters  to  any  font  by  either  sketching  in  an  entirely  new  set  of  segments  or  by 
copying  an  existing  character  from  any  defined  font. 

6.3.21.  Site  View  User  Interface 

The  class  SITE-VIEW-MIXIN  is  the  heart  of  the  SITE  CONTROLLER  user  interface.  Although 
methods  of  this  class  only  implement  mouse  commands,  99%  of  the  user's  interaction  with  SITE 
CONTROLLER  is  through  methods  of  SITE-VIEW-MIXIN. 

6.3.21.1.  Substrata  of  Highor-Ordsr  Procsdures 

In  order  to  reduce  development  effort,  ease  maintenance,  and  decrease  window  system  depen¬ 
dence,  the  top-level  user  interface  procedures  rest  on  a  tower  of  higher-order  procedures.  At  the 
base  is  one  of  the  most  powerful — the  method  :GET-FROB-FROM-USER.  This  takes  as 
argumorts  a  CLOSEST-PRCXZEDURE,  which  will  cough  up  the  closest  relevant  object  to  any 
point  in  the  projection  plane,  a  documentation  string  that  will  tell  the  user  what  is  expected  of 
him,  and  mformation  about  when  to  abort  and  what  to  return  after  an  abort.  The  only  restric¬ 
tion  on  CLOSEST-PRCXTEDURE  is  that  it  return  an  object  capable  of  responding  to  the 
:HIGHUGHT-SELF  and  :UNHIGHLIGHT-SELF  messages. 

The  basic  user  interface  of  SITE  CONTROLLER  is  operator  prefix,  the  opposite  of  the  Macintosh 
interface.  For  example,  on  the  Macintosh  one  selects  an  object  with  the  mouse  and  then  pulls 
down  an  operation  from  a  menu.  In  SITE  CONTROLLER,  one  specifies  the  operation  to  be 
performed  widr  a  mouse  chord  and  then  chooses  one  or  more  objects  from  those  that  are  legal.  A 
pereniual  problem  on  the  Macintosh  is  selection,  i.e.,  in  a  complex  drawing  the  user's  intent  in 
clicking  the  mouse  on  a  particular  pixel  is  unclear.  Given  the  complexity  of  comprehoisive  site 
models,  this  problem  would  be  100  times  worse  in  SITE  CONTROLLER  if  not  for  the  fact  that  the 
search  space  is  restricted  as  soon  as  the  operation  is  known. 

The  following  illustrates  the  utility  of  this  way  of  constructing  user  interface  methods. 

(defmethod  { :get-triangle-f rom-user  site-view-mixin) 

(Sioptional  (doc  “Click  inside  the  triangle  you  want  to  select")) 
(check-site-and-surface) 

(send  self  :get-f rob-from-user 

(lambda  (x  y)  (send  (send  site  .-current-surface) 

: triangle-containing  x  y) ) 

doc)  ) 

GET-TRIANGLE-FROM-USER  takes  a  single  optioruil  argument,  a  documentation  string  to  be 
displayed  while  the  user  is  rolling  the  mouse  around  the  site.  The  CHECK-SITE-AND- 
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SURFACE  procedure  displays  a  standard  error  message  if  this  method  is  invoked  on  a  wirvdow 
that  is  not  currently  viewing  a  particular  site  with  a  defined  "current  surface"  (i.c.,  the  one 
that  is  selected  for  editing).  The  meat  of  this  method  is  in  the  CLOSEST-PROCEDURE,  an 
unnamed  lambda  that  takes  arguments  X  and  Y  and  asks  the  site's  current  surface  to  return  the 
triangle  containing  the  point  specified  by  X  and  Y.  Not  only  is  this  7  line  (actually  only  5  on 
the  wide  Lisp  Machine  screen)  procedure  refreshingly  simple  for  the  programmer,  but  the 
selection  problem  is  neatly  side-stepped.  We  need  not  consider  whether  the  mouse  was  clicked 
closer  to  a  surveyed  point  or  a  triangulation  edge  and  therefore  if  that  might  be  what  the  user 
intended. 

In  a  similar  vein,  there  are  procedures  that  query  the  user  for  surveyed  points,  triangulation 
edges,  polygons,  lot  boundaries,  lot  boundary  end  points,  site  features,  road  segments,  road  inter¬ 
sections,  road  graph  arcs,  pieces  of  text,  etc. 

6.3.21.2.  Mous*  Commands 

All  the  mouse  commands  defined  by  SITE-VIEW-MIXIN  may  be  spUt  up  into  the  following  cat¬ 
egories:  screen  scaling,  terrain  model  editing,  lot-boundary  related,  utility,  surface-visualiza¬ 
tion,  site  features,  geometry  bag,  and  miscellaneous. 

The  screen  scaling  category  coiuists  of  an  unremarkable  collection  of  zoom,  unzoom,  zoom  to  fit, 
scroll,  and  refresh.  The  only  mildly  irmovative  idea  here  is  the  following:  for  scrolling,  the 
user  is  presented  with  two  pop-up  menus;  the  first  requests  a  direction  (left,  right,  up  or  down), 
the  second  offers  a  predefined  list  of  amounts;  if  the  user  waves  the  mouse  out  of  the  second 
menu,  he  is  prompted  in  a  typeout  window  to  type  in  an  arbitrary  scrolling  amount. 

Terrain  model  editing  commands  constitute  the  largest  category.  There  are  simple  commands 
for  adding  surveyed  points  and  contours,  more  powerful  commands  that  define  prospective  sur¬ 
faces  arui  calculate  relationships  among  surfaces,  a  command  to  actually  combine  a  real  surface 
with  one  or  more  prospective  surfaces,  a  management  command  to  select  the  current  surface  on 
which  other  commands  operate,  and  finally  commands  that  allow  sophisticated  users  to 
manipulate  the  data  structures  such  as  the  list  of  forced  connections. 

Surface  visualization  commands  allow  the  user  to  request  a  single,  mouse-specified  profile  cut 
through  the  current  surface  or  a  pop-up  3D  view  from  a  mouse  and  keyboard-sp)ecified  view¬ 
point.  This  category  also  contains  commands  to  select  which  site  is  to  be  edited  in  this  view, 
from  that  site  which  surfaces  are  to  be  displayed,  and  which  site  features  and  information  are 
to  be  marked  as  well. 

Utility  commands  provide  a  user  interface  to  the  ruler,  scale  and  area-calculation  facilities. 
However,  the  most  interesting  command  in  this  category  is  the  dynamic  mouse  facility.  When 
selected,  this  lets  the  user  roam  over  the  site  with  the  mouse  while  information  about  the 
terrain  at  the  mouse  position  is  dynamically  updated  in  a  statistics  window.  Information 
available  depends  on  the  mouse  buttons  and  shift  keys  depressed,  but  includes  2D  position,  ele¬ 
vation  on  the  current  surface  (either  crudely  or  smoothly  interpolated),  and  gradient  on  both 
the  big  triangles  and  the  triangular  mesh  of  the  smooth  interpolation  data  structures.  This 


might  be  useful  to  a  civil  engineer  quickly  checking  the  position  of  site  objects  and  proved  very 
useful  while  developing  software.  The  gradient  display  facility  was  implemented  while  de¬ 
bugging  the  smooth  interp>olation  code — it  was  possible  to  actually  see  the  gradient  discontinu¬ 
ity  across  big  triangle  boundaries  when  I  had  misinterpreted  Nielson's  notation  for  nanung 
edges  (edge  1  is  opposite  vertex  1).  Ten  minutes  of  graphics  programming  sufficed  to  save 
several  hours  of  head  scratching  and  staring  at  code. 

Site  feature  and  geometry  bag  conunands  all  serve  to  add  to  those  parallel  data  structures. 
Miscellaneous  commands  include  those  having  to  do  with  roads  and  utility  lines. 

6.4.  Mine  Planning  Extension 

The  extensibility  of  LAND  HACKER  and  SITE  CONTROLLER  was  really  put  to  the  test  for  two 
weeks  when  I  wanted  to  extend  the  software  to  represent  and  perform  atialysis  with  3D 
information  about  an  Appalachian  coal  mine.  Seams  of  coal  were  deposited  in  the 
Appalachias  millions  of  years  ago  when  the  area  was  a  lake  bed.  Thus,  any  individual  coal 
seam  is  at  about  the  same  elevation  above  sea  level  for  thousands  of  square  kilometers.  Where 
the  mountains  are  high,  the  seam  will  run  to  the  edge  of  the  mountain  and  not  exist  again  until 
one  is  across  the  valley  on  another  ridge.  Surface  mining,  a.k  ji.  strip  mining,  in  the 
Appalachias  involves  ripping  the  tops  off  the  mountains  and  hurling  them  into  the  valleys  be¬ 
low  until  the  coal  seam  is  exposed,  then  moving  in  with  shovels  and  trucks  to  cart  away  the  me¬ 
ter-thick  coal  itself  before  ripping  down  another  dozen  meters  to  the  next  seam. 

A  dragline  is  the  most  important  tool  in  this  kind  of  mining.  This  machine  throws  a  bucket  one 
hundred  meters  out  in  front  of  itself  and  then  drags  it  back  with  steel  cables,  filling  the  bucket 
in  the  process.  A  $20  million  machine  can  move  3(XX)  cubic  meters  of  earth  per  hour.  (These 
machines  are  custom  built  and  assembled  on-site  as  they  are  too  large  to  be  moved  by  truck  or 
rail.)  A  large  mine  would  likely  only  have  one  dragline  and  the  entire  mine's  productivity  is 
determined  by  this  one  machine's  productivity.  However,  if  the  excavation  plan  is  not 
optimal,  a  lot  of  time  will  be  spent  moving  the  dragline  from  one  place  to  another 
("deadheading"),  building  a  "foot"  on  which  the  dragline  can  sit  and  operate,  or  moving  the 
two-meter-thick  power  cord  (ttrere  are  no  transmissions  strong  enough  to  handle  the  power  of  a 
dragline;  hence  all  the  dragline's  motors  are  electric). 

Extending  the  LAND  HACKER  system  proved  remarkably  easy.  The  class  MINE  adds  only  five 
instance  variables  to  those  it  inherits  from  SITE.  These  variables  contain  the  boring  data,  coal 
seam  data  structures,  and  mining  plan.  Instances  of  the  class  SEAM  contain  a  top  bounding  sur¬ 
face,  a  bottom  bounding  surface,  a  name  (Appalachian  coal  seams  are  all  well-known  to  those  in 
the  industry  and  have  colorful  names  such  as  "Stockton  A  Upper"),  and  a  lithology  that  de¬ 
scribes  the  composition  of  the  seam  (e.g.  coal,  shale,  boney  coal,  siltstone).  All  the  surveyed 
points  in  the  seam  bounding  surfaces  are  instances  of  the  class  SEAM-SURVEYED-POINT, 
which  inherits  from  SURVEYED-POINT  and  adds  no  methods  but  contains  a  single  important 
instance  variable:  the  boring  layer,  which  is  a  data  structure  describing  measurements  made  of 
the  material  found  at  this  location,  such  as  the  percentage  of  sulphur  or  the  BTUs/pound  ob¬ 
tainable  by  burning  the  coal. 
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6.4.1.  Boring  Data 


All  the  information  about  a  site's  stratigraphy,  i.e.  what  lies  under  the  surface,  is  obtained 
from  borings,  A  boring  is  obtained  by  extracting  a  narrow  cylinder  from  the  ground,  perhaps  as 
narrow  as  10  cm  in  diameter  and  as  deep  as  the  volume  being  cor\sidered  for  mining.  An  object  of 
the  class  BORING  stores  the  mine  with  which  the  boring  is  associated,  the  3D  position  of  the 
top  of  the  boring,  the  maximum  boring  depth,  the  date  on  which  the  boring  was  taka\,  the  ruime 
of  the  person  who  supervised  the  measuremaits,  an  identification  number  for  the  borir^ 
corresportding  to  paper  logbooks,  a  string  of  optional  comments,  and,  most  importantly,  a  list  of 
boring  layers. 

Each  object  of  the  class  BORING-LAYER  maintains  the  following  data:  the  boring  of  which  it 
is  a  part,  the  rtame  of  the  seam  from  which  this  cylindrical  piece  came,  a  symbol  giving  the 
lithology  of  the  piece,  the  elevation  above  sea  level  of  the  top  of  the  sample,  the  elevation 
above  sea  level  of  the  bottom  of  the  sample,  and  some  coal  quality  parameters  that  are  used 
only  if  it  is  a  sample  of  a  coal  seam. 


Figure  6.16  Topography  of  the  Hobet  mine  in  West  Virginia,  with  boring  locations  su- 
p>erimposed  on  the  contour  map.  Note  the  detailed  description  of  a  single  boring  in  the 
upper  ri^t  window. 

6.4.2.  Building  Seams  from  Borings 

Once  the  boring  data  structures  have  been  constructed  from  raw  textual  tables,  a  ntethod  of  the 
MINE  class  generates  seam  objects.  The  hrst  step  is  to  look  through  all  the  boring  layers  in  all 
the  borings  and  build  a  set  of  all  coal  seam  names  (this  version  of  the  software  only  worries 
about  coal  seams).  For  each  name,  a  help>er  method  loops  through  each  boring  again  and  hnds 
the  sample  ttuit  correspoinls  to  that  seam  (if  any).  Each  boring  that  contains  information  about 
a  seam  contributes  two  objects  of  the  class  SEAM-SURVEYED-POINT,  one  to  the  top  surface  and 
one  to  the  bottom.  When  all  the  borings  have  been  examined,  the  top  and  bottom  surfaces  are 
triangulated  and  the  finished  seam  added  to  the  mine  object's  list  of  seams. 
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This  technique  is  really  half-baked  because  it  assumes  that  a  coal  seam  covers  the  entire  con¬ 
vex  hull  of  the  borings  that  contain  samples  of  that  seam.  In  reality,  the  fact  that  a  boring  con¬ 
tained  no  sample  of  a  seam  should  tell  us  that  the  seam  disappears  in  that  location. 

6.4.3.  Representing  a  Mining  Pian 

Excavation  is  conducted  in  parallel  strips,  with  the  dragline  moving  back  and  forth  on  a  yet-to- 
be-excavated  strip  while  ripping  away  at  the  current  one.  This  software  models  a  stripping 
plan  as  a  collection  of  parallelograms,  each  one  divided  into  a  number  of  strips  of  reasoruble 
width.  The  stripping  software  is  built  on  a  substrate  of  generic  parallelogram  modelling  and 
user  interfoce  code.  Objects  of  the  class  SIMPLE-PARALLELOGRAM  contain  a  b«»se  point  and 
two  vectors  that  define  the  geometrical  object  as  well  a  cache  of  four  orimted  lines  that  will  be 
useful  for  quickly  answering  point  inclusion  queries.  The  nnost  important  user  interface  method 
is  CET-PARALLELOGRAM-FROM-USER,  which  makes  use  of  the  :GENERIC-MOUSE- 
HANDLER  higher-order  procedure  to  let  the  user  manipulate  the  arms,  orientation,  and  global 
position  of  the  parallelogram. 

Objects  of  the  classes  STRIP  and  STRIP-COLLECTION  both  inherit  from  the  class  SIMPLE- 
PARALLELOGRAM,  but  strip  collections  contain  daughter  strips  that  store  a  sequence  number 
(in  the  mine's  overall  excavation  plan).  Methods  of  the  class  STRIP-COLLECTION  are  pri¬ 
marily  concerned  with  dividing  the  parallelogram  into  fixed-width  strips.  Methods  of  the 
class  STRIP  are  primarily  analysis-oriented. 

The  following  medtod  shows  some  of  the  power  that  is  inherent  in  LAND  HACKER: 

(defmethod  ( :analyze-case  strip)  (top-seeun  bottom-seam) 

(declare  (values  yds -of -overburden  effective-strip-ratio  tons-of -coal ) ) 
(let*  ( (top-bottom-sfc  (send  top-seaun  : bottom-surface ) ) 

(bottom-top-sfc  (send  bottom-seam  :top-surface) ) 
(bottom-bottom-sfc  (send  bottom-seam  ibottom-surface) ) ) 

(when  (and  (send  self  ;are-you-contained-within?  top-bottom-sfc) 

(send  self  :are-you-contained-within?  bottom-top-sfc) 

(send  self  ;are-you-contained-within?  )Dottom-bottom-sfc) ) 

(let*  ((strip-sfc  (send  self  :generate-surface  top-bottom-sfc)) 

(overburden  (send  strip-sfc 

: volume -between -you -and- larger -surface 
bottom-top-sfc) ) 

( overburden-plus -coal 

(send  strip-sfc  : volume-between-you-and-larger-surface 
bottom-bottom-sfc) ) 

( just-the-coal  (-  overburden-plus -coal  overburden)) 
(yds-of-coal  (cubic-feet-to-cubic-yards  just-the-coal)) 
(tons-of-coal  (*  yds-of-coal  *tons-per-cubic-yd-of-coal*) ) 
(yds -of -overburden  (cubic-feet-to-cubic-yards  overburden) ) 
(effective-strip-ratio  (/  yds -of -overburden  tons-of-coal))) 
(values  yds -of -overburden  effective-strip-ratio  tons-of-coal))))) 

This  procedure  calculates  how  much  work  will  have  to  be  done  to  get  at  the  coal  under  this 
strip.  Its  arguments  are  two  seams  and  the  assumption  is  that  excavation  is  from  the  bottom  of 
the  top  seam  to  the  top  of  the  bottom  seam.  The  method  first  checks  to  make  sure  that  the 
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strip's  planar  projection  is  contained  within  the  planar  projections  of  the  seams.  It  then  projects 
itself  onto  the  bottom  surface  of  the  top  seam  to  create  a  surface  for  use  in  volumetric  calcula¬ 
tions.  At  this  point,  calculating  the  Ofverburden,  i.e.,  amount  of  worthless  rock  that  must  be 
excavated  to  get  at  what  is  presumably  valuable  coal,  is  as  simple  as  sending  a  message  to  the 
strip  surface  to  ask  the  volume  between  it  and  the  top  surface  of  the  bottom  seam.  Another  sim¬ 
ilar  call  serves  to  get  the  volume  irKluding  the  coal  under  the  strip.  A  simple  subtraction  yields 
the  volume  of  coal  and  a  division  determines  the  all-important  strip  ratio  —  the  amount  of  rock 
that  must  be  removed  per  ton  of  coal.  If  this  ratio  is  excessive,  then  mining  an  area  may  be 
uneconomical. 

6.4.4.  User  Interface 

All  the  user  interface  methods  for  mining  are  associated  with  the  class  MINE-VIEW-MIXIN, 
which  must  be  combined  with  SITE-VIEW-MIXIN  to  do  anything  really  useful.  The  addi¬ 
tional  display  capabilities  contributed  by  this  class  are  the  ability  to  superimpose  boring  loca¬ 
tions  and/or  detailed  boring  information  on  the  site,  an  excavation  plan  display  capability, 
and  a  method  for  showing  a  simultaneous  vertical  cross  section  through  all  the  subsurfaces. 

The  user  interaction  methods  can  be  divided  into  the  following  categories;  stripping  plan  ma¬ 
nipulation,  boring  input  and  query,  point  and  strip  productivity  analysis,  hypothetical  ap¬ 
pearance,  and  spreadsheet  interface. 

Stripping  plan  manipulation  methods  allow  the  use  to  specify  parallelograms  to  be  excavated, 
divide  them  up  into  strips,  and  number  the  strips  automatically  or  manually.  Boring  query 
methods  are  a  kind  of  hypertext  where  clicking  on  a  boring  reveals  detailed  ir\formation  about 
it  in  another  window.  Productivity  analysis  uses  either  the  method  described  in  the  preceding 
section  for  strip  analysis  or  aiwther  method  based  on  point  interpolation  to  answer  questions 
about  the  amount  of  work  required  to  extract  coal  and  the  expected  quality  and  value  of  that 
coal.  Hypothetical  appearance  methods  show  the  topography  following  excavation,  i.e., 
what  would  the  site  look  like  if  we  ripped  down  to  the  Stockton  A  seam?  (Unfortunately,  this 
software  does  not  model  the  effect  of  hurling  the  spoil  down  into  the  valley,  but  assumes  that 
the  excavated  material  magically  disappears.)  Finally,  the  spreadsheet  interface  crardcs  out 
excavation  data  to  a  flle  readable  by  1-2-3  or  Excd  so  that  spreadsheet  models  may  be  used  to 
determine  excavation  costs.  Unfortunately,  as  there  was  no  popular  commercial  spreadsheet 
program  for  the  Lisp  Machine,  this  interface  is  static  rather  than  dynamic,  i.e.,  one  cannot 
change  the  stripping  plan  and  see  the  spreadsheet  numbers  up>date  in  real  time. 

6.5.  Actor  Simulator 

SITE  CONTROLLER  fundamentally  corrsists  of  a  mixing  of  LAND  HACKER  and  an  actor-based 
simulation  system. 

6.5.1.  Simulation  Control 

Standard  sites  in  SITE  CONTROLLER  inherit  from  the  classes  SIMULATING-SITE-MIXIN  and 
SIMULATOR-MIXIN.  SIMULATOR-MIXIN  contributes  instance  variables  that  keep  track  of 


which  actors  are  being  simulated,  simulation  parameters  such  as  how  much  time  to  advance 
with  each  tick,  and  simulation  state  variables  such  as  the  current  time.  Methods  of  the 
simulator  use  actor  prototypes  from  a  scenario  to  initialize  a  simulation.  An  actor  prototype  is 
actually  represented  with  the  same  class  hierarchy  as  a  real  actor  and  it  contains  all  the 
information  that  can  be  specified  before  simulation  about  what  its  corresponding  actors  should 
do.  Because  simulation  is  often  probabilistic,  it  is  useful  to  distinguish  between  an  actor 
prototype,  which  reflects  the  user's  intent  in  general  for  a  simulation,  and  an  actor,  whose  state 
variables  reflect  probabilistic  outcomes  in  a  particular  simulation.  Scenarios  are  nothing  more 
than  named  collections  of  actor  prototypes. 

6.5.2.  Actor  Class  Structure 

The  base  class  ACTOR  keeps  track  of  the  following  information:  the  site  where  simulation  is 
taking  place,  model  space  position,  time  of  last  update  tick  from  simulator  (i.e.,  the  site),  cre¬ 
ation  time  (at  which  the  actor  begins  to  exist),  prototype  object  that  created  the  actor  object  (or 
the  symbol  rPROTOTYPE  if  the  actor  is  itself  a  prototype),  a  statistics  window  in  which  dy¬ 
namic  information  is  to  be  displayed  (NIL  if  no  display  is  enabled),  and  a  perspective  view 
window  in  which  to  display  the  view  from  an  object's  "front  wmdow." 

User  interface  menus  are  automatically  gerterated  from  an  actor  object's  response  to  the 
rSETTABLE-PARAMETERS  and  :RUN-TIME-SETTABLE-PARAMETERS  messages,  correspond¬ 
ing  to  those  state  variables  that  may  be  changed  in  an  actor  prototype  and  in  an  actively  simu¬ 
lated  actor,  respectively.  Responses  to  these  messages  are  the  result  of  appending  lists  con¬ 
tributed  by  methods  of  all  of  the  superclasses  from  which  a  particular  actor  inherits.  When 
the  user  wants  to  modify  a  parameter,  he  is  first  presented  with  an  automatically-generated 
menu  of  parameter  names.  After  he  has  chos«t  a  parameter,  depending  on  the  specification  list 
from  the  :SETT ABLE-P ARAM 1 1  bRS  methods,  he  is  prompted  for  a  path,  polygon,  a  choice 
from  a  constrained  list  of  symbols,  another  actor  prototype,  one  of  the  standard  Lisp  Machine 
data  types,  etc.  as  appropriate.  Once  again,  the  priiKiple  of  automating  the  generation  of  user 
interface  keeps  the  class  hierarchy  extensible,  for  it  is  just  as  easy  to  add  to  the  user  interface 
as  it  is  to  add  instance  variables  and  methods. 

Although  virtually  all  actors  are  in  fact  displayable,  the  state  and  behaviors  necessary  to  sur¬ 
vive  on  the  screen  are  expressed  in  a  separate  class,  DISPLAY ABLE-ACTOR-MIXIN.  The  in¬ 
stance  variables  contain  the  following  state:  whether  the  actor  should  currently  be  visible,  ex¬ 
actly  how  the  character  was  drawn  on  the  screen  last  time  (so  that  it  can  be  erased  if  need  be), 
information  for  displaying  either  a  bit-map  or  vector-font  character  at  the  appropriate  scale 
and  rotation. 

All  drawing  is  done  by  sending  messages  to  the  site.  The  site  is  capable  of  handling  these  mes¬ 
sages  because  it  inherits  from  SIMULATING-SITE-MIXIN  and  hence  keeps  track  of  which 
views  on  which  screens  are  currently  active  for  simulation.  SITE  CONTROLLER  is  capable  of 
showing  a  simulation  at  different  scales  and  in  different  locations  on  multiple  windows. 

PATH-FOLLOWING-ACTOR  is  a  class  fundamental  to  all  simulated  construction  vehicles. 
Actors  inheriting  from  this  class  can  follow  a  segmented  path  at  predetermined  velocities. 
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Furthermore,  this  class  defines  the  base  method  for  the  TICK  message  from  the  simulator. 
Actually,  the  ACTOR  class  defines  a  whopper  for  :TICK,  which  executes  before  any  of  the  regu¬ 
lar  methods,  both  base,  before  and  after,  and  immediately  returns  if  the  current  simulation  time 
is  not  later  than  the  actor's  creation  time.  If  the  simulation  time  is  after  the  actor's  creation 
time,  i.e.,  the  actor  "exists,"  PATH-FOLLOWING-ACTOR's  :TICK  method  first  calculates  the 
time  elapsed  since  the  last  tick,  uses  that  number  to  generate  a  new  position  (determining  in  the 
process  whether  a  new  path  segment  is  needed),  and  sends  a  :DRAW-SELF  message  so  that 
DISPLAYABLE-ACTOR-MIXIN  will  erase  the  old  image  if  necessary  and  draw  a  new  one  at 
the  updated  position. 

Actors  that  inherit  from  TERRAIN-INTERACTION-MIXIN  calculate,  after  every  TICK 
message,  the  surface  model  triangle  they  are  on,  what  kind  of  terrain  that  is,  the  gradient,  and 
their  elevation.  Reasonable  efficiency  is  achieved  by  caching  the  current  triangle  and  orUy 
looking  for  arusther  when  the  current  triangle  reports  that  its  projection  in  the  x-y  plane  does 
n«  t  contain  the  actor's  current  projection.  When  the  actor  has  run  off  the  current  triangle,  the 
code  tries  to  walk  through  the  triangulation  from  the  current  triangle  rather  than  start  a  global 
search,  which  is  used  only  as  a  last  resort. 

ACT  OR-TERRAIN-SCROLLING-MIXIN  allows  a  user  to  monitor  an  overhead  view  of  a 
vehicle's  surround  even  as  the  vehicle  moves.  After  each  :TICK,  the  window  (if  any)  is  scrolled 
so  that  the  vehicle  remains  in  the  window's  center  as  the  terrain  slides  underneath. 

VEHICLES  inherit  from  ACTOR-TERRAIN-SCROLLING-MIXIN  and  PATH-FOLLOWING- 
ACTOR,  then  add  standard  characteristics:  maximum  velocity,  mass,  engine  operating  mea¬ 
surements,  maintenance  history,  and  the  operator  identity.  Methods  of  the  class  VEHICLE  can 
display  additional  statistics  in  a  window  and  update  an  entire  monitoring  frame  if  the  user 
wants  to  monitor  a  vehicle  in  detail,  i.e.,  by  looking  at  simulated  engine  gauges  and  the  opera¬ 
tor's  view.  LAND-VEHICLEs  add  the  abilities  to  declare  their  propulsion  system  to  be  either 
wheels  or  tracks  and  to  predict  the  likely  direction  of  the  op>erator's  gaze. 

Bulldozers  are  modelled  by  the  class  KILLDOZER  (after  the  1970's  horror  film  of  the  same 
title  wherein  an  alien-possessed,  operator-less  bulldozers  murders  workers  in  the  middle  of  the 
jungle  until  a  final  epic  battle  with  a  human-operated  shovel).  A  bulldozer's  fundamental 
behavior  is  controlled  by  its  MODE  instance  variable.  Possible  modes  include  :IDLE,  where  the 
bulldozer  is  just  driving  around,  :CUT-TO-HEIGHT  where  the  blade  will  remain  at  a  constant 
elevation  above  sea  level,  :TAKE-OFF  where  the  blade  will  slice  a  fixed  amount  off  the  top  of 
a  surface,  and  :FOLLOW-DESIGN  where  the  blade  will  remain  on  an  arbitrary  design  surface. 

In  addition  to  the  mode,  various  state  and  characteristic  variables  are  maintained,  such  as  the 
elevation  abov  e  sea  level  of  the  bottom  of  the  blade,  the  force  on  the  blade,  the  accumulated 
soil  in  front  of  the  blade,  and  the  blade  width. 

The  most  interesting  capability  of  a  KILLDOZER  object  is  that  of  creating  a  new  surface  that 
shows  what  the  current  surface  would  look  like  after  excavation.  To  do  this,  die  object  incre¬ 
mentally  builds  up  two  sets  of  points,  one  to  form  the  convex  hull  of  the  new  prospective  surface 
patch  and  one  to  define  the  actual  path  of  the  blade.  Forced  connections  are  inserted  so  that 
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the  original  surface  outside  the  hull  is  unaffected  by  the  blade  path  elevations  and  also  so  that 
die  area  undemeadi  the  blade  is  unaffected  by  elevations  outside  the  blade  path.  The  area  in 
between  the  hull  and  the  blade  piath  is  allowed  to  take  on  any  shape  (presumabl/  it  will  be  a 
slop>e  from  the  original  surface  down  to  the  blade  path).  Without  the  forced  connections,  the 
resulting  surface  might  look  like  almost  anything  and  would  certainly  not  have  a  neady- 
carved  trench  in  it. 

SURVEYING-VEHICLEs  inherit  from  TERRAIN-INTERACTION-MIXIN  and  TRUCK.  These 
actors  maintain  an  augmentation  surface,  which  will  be  filled  with  surveyed  points  at  periodic 
intervals  as  the  vehicle  drives  over  a  piece  of  terrain  equipped  with  some  kind  of  location 
system.  These  actors  are  useful  for  simulating  ultimate  real-world  practice  where  surveys, 
particularly  of  hazardous  waste  sites,  will  be  conducted  from  within  enclosed  v^icles  taking 
advantage  of  precise  location  systems  such  as  GPS.  There  are  also  more  specialized  surveying 
vehicle  classes  that  sample  radiation  or  hazardc  s  waste  barrels  in  addition  to  standard 
topographic  data. 

6.5.3.  Personnel  Database 

For  numerous  operational,  legal,  and  historical  reconstruction  reasons,  it  is  worthwhile  to  keep 
accurate  records  of  which  operators  performed  which  operatic»is  on  a  site.  An  object  of  class 
OPERATOR  contains  the  following  data:  name,  years  of  employmait,  start  date,  accident  and 
injury  history,  license  information,  machine  qualifications,  hourly  cost,  previous  sites,  and 
previous  employer.  There  are  the  beginnings  of  a  hypertext  system  in  SITE  CONTROLLER 
where  clicking  on  displayed  attributes  of  objects  such  as  operators  would  hop  to  descriptions  of 
the  attribute  value. 

6.5.4.  Terrain  Objects 

Any  particular  kind  of  terrain  is  represented  as  an  object  of  a  class  that  inherits  from  BASIC- 
TERRAIN.  Any  kind  of  terrain  can  give  information  about  the  coefficients  of  friction  and  drag 
for  wheels,  tracks  or  feet  (human).  In  addition,  terrain  objects  know  how  to  draw  and  describe 
themselves. 

6.6.  Real-World  Site  Control 

Caterpillar  used  a  copy  of  SITE  CONTROLLER  to  monitor  and  oversee  the  operation  of  an 
autonomous  mining  truck  (AMT).  The  AMT  is  built  on  top  of  a  $600,000, 1200  horsepower  dump 
truck.  The  standard  vehicle  is  fitted  with  GPS  and  inertial  navigation  systems  and  an  on¬ 
board  computer  capable  of  learning  several  routes.  I  spent  a  few  weeks  extending  SITE 
CONTROLLER  to  work  in  real  time  with  the  AMT  and  then  travelled  to  the  Arizona  desert  to 
install  the  software  and  watch  it  work.  The  programmers  at  Caterpillar  made  life  very  easy 
for  SITE  CONTROLLER  by  providing  a  clean  high-level  interface  to  the  truck  via  an  RS-232  con¬ 
nection  to  a  radio  modem. 
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6.6.1.  Basic  System  Structure 

Each  real-world  vehicle  is  shadowed  by  an  actor  slave  in  SITE  CONTROLLER.  The  slave  is  sup¬ 
posed  to  embody  all  the  most  recent  knowledge  about  the  real  vehicle's  position,  speed,  and  any 
other  available  information.  Communication  with  a  real  vehicle  is  accomplished  by  sending 
messages  to  the  corresponding  slave. 

Communicaticm  to  die  vehicle  occurs  only  as  a  consequence  of  some  user  action.  Consequently, 
sending  packets  is  done  by  the  normal  SITE  CONTROLLER  process — although  in  practice  die 
simulation  is  not  held  up  waiting  for  the  serial  line  because  the  Lisp  Machine  buffers  the  output 
bytes  and  transmits  them  at  the  selected  baud  rate  from  a  special  "serial  output"  process.  Input, 
on  the  other  hand,  is  received  asynchronously  by  a  special  communications  monitor  process  that 
periodically  updates  a  shared  data  structure  with  newly-received  packets.  All  communica¬ 
tions  in  and  out  may  be  archived  in  a  file  that  is  replayable  to  show  the  activity  at  a  site  on  a 
particular  day,  with  the  user  able  to  step  forward  m  time  at  his  own  pace. 

All  the  software  is  written  to  cope  with  an  arbit'ary  number  of  vehicles,  although  in  practice 
only  one  truck  was  ever  available  with  the  appropriate  on-board  hardware. 

6.6.2.  Actor  Class  Extensions 

In  order  to  ensure  that  SITE  CONTROLLER  would  work  when  plugged  in,  I  added  the  class 
SIMULATE-CAT-TRUCK-MIXIN  that  drives  aroimd  a  site  in  simulation,  periodically  sending 
out  status  packets  to  tfie  serial  port.  During  testing,  I  connected  the  output  and  in'^ut  pins  of  the 
serial  port  so  that  signals  looped  back  into  the  computer.  A  packet-reading  process  would  even¬ 
tually  notify  an  object  inheriting  from  the  class  CAT-SLAVE-MIXIN  that  packets  li  1  been 
received.  Each  time  a  packet  came  in  with  an  updated  position,  one  could  see  the  CAT-SLAVE 
actor  jump  to  coincide  with  the  SIMULATE-CAT-TRUCK  actor.  This  method  of  testing  resulted 
in  only  one  line  of  code  having  to  be  changed  when  the  real  truck  was  hooked  up. 

6.6.3.  User  Interface 

All  user  interaction  with  the  AMT  is  supported  by  mouse-accessible  commands  added  by  the 
class  CAT-SITE-VIEW-MIXIN.  There  are  commands  to  request  a  vehicle's  status,  change  a  ve¬ 
hicle's  velocity,  and  select  a  vehicle's  route.  Utility  commands  include  such  items  as  resetting 
the  communications  history  and  saving  the  current  history  to  a  file.  Finally,  there  are  com¬ 
mands  to  control  replay  of  communications  from  a  file. 

In  addition  to  mouse  commands  supported  by  the  site  view  window,  there  is  a  hyjiertext 
facility  built  into  the  communications  display  window.  Each  packet  occupies  a  line  in  a  tall, 
narrow  window  that  scrolls  up  as  new  packets  are  received.  There  are  scroll  bars  that  enable 
the  user  to  select  any  portion  of  the  history  and  hypertext  hooks  that  pop  up  a  full  description 
of  any  packet  that  is  mouse-clicked. 
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6.6.4.  Communications 


Communication  was  accomplished  with  1200  baud  radio  modems.  All  communication  must  take 
the  form  of  a  packet,  which  starts  with  an  STX  character  and  mds  with  an  ETX.  Each  packet 
contains  vehicle  identification  as  well  as  a  CRCC  error  detection  word.  All  packets  inherit 
from  the  class  DATA-PAGKET.  Packets  going  to  a  vehicle  inherit  from  the  class  PACKET-TO 
VEHICLE  and  incoming  packets  inherit  from  PACKET-FROM-VEHICLE;  methods  of  these  two 
classes  are  where  the  meat  of  transmission  and  self-description  occur.  There  is  a  leaf  class 
corresponding  to  each  distinct  packet  type.  Typical  packet  types  include  the  following; 
SELECT-ROUTE,  REQUEST-STATUS,  STATUS-FROM- VEHICLE  (containing  position), 
HEALTH-FROM- VEHICLE  (engine  and  load  statistics),  MESSAGE  (containing  arbitrary 
ASCII  text  to  be  displayed  to  the  user  of  SITE  CONTROLLER  or  a  human  in  the  vehicle,  if  any). 

Packets  are  first  collected  in  raw  form  by  a  very  simple  parser  that  just  looks  for  STX,  ETX  and 
escape  characters  used  to  precede  STX  or  ETX  bytes  that  must  occur  in  the  middle  of  a  packet. 
All  the  bytes  between  STX  and  ETX  are  handled  over  to  a  firute  state  machine  parser  that 
picks  out  the  vehicle-id,  message  type,  the  type-dependent  data  bytes,  and  the  CRCC  word. 
The  parser  creates  either  a  GARBLED-PACKET  object  or  a  packet  object  of  the  appropriate 
class.  If  the  packet  is  otiierwise  OK,  but  the  CRCC  word  did  not  check  then  a  real  packet  is 
created  anyway,  but  its  CRCC-OK?  instance  variable  is  set  to  NIL.  This  mi^t  be  useful,  for 
example,  if  one  received  a  human-readable  ASCII  message  from  a  vehicle  in  a  hostile  environ¬ 
ment  and  getting  the  message  quickly  with  one  character  wrong  might  be  better  than  not  seeing 
it  at  all  until  a  perfect  message  could  be  transmitted. 

Breaking  apart  the  data  bytes  into  appropriate  fields  is  left  to  methods  of  the  specialized 
packet  classes.  After  this  is  complete,  the  completed  packet  is  pushed  onto  the  front  of  a  list 
containing  all  packets  received.  This  list  is  the  value  of  a  global  variable  and,  since  all  Lisp 
Machine  processes  run  in  a  single  virtual  address  space,  is  accessible  to  the  SITE  CONTROLLER 
user  process. 

A  note  on  error  control  is  in  order  here.  A  standard  quick-and-dirty  error  detection  method  is 
the  oi^byte  checksum,  i.e.,  transmittirtg  the  result  of  XOR'ing  all  the  bytes  in  the  packet  to¬ 
gether.  This  is  better  than  nothing,  but  two  single-bit  errors  can  cancel  each  other  in  the  XOR, 
thus  resulting  in  a  corrupted  transmission  being  accepted.  CRCC,  or  cyclic  redundancy  code 
check,  error  detection  works  by  regarding  the  entire  message  as  a  single  bit  string,  say  N  bits 
long.  These  N  bits  are  taken  to  be  the  coefficients  of  an  Nth  order  polynomial  over  the  integers 
mod  2,  i.e.,  a  polynomial  that  consists  only  of  monomials  such  as  .  The  coefficients  are  re¬ 
stricted  to  take  on  values  1  or  0  and  if  we  divide  this  polynomial  by  a  generating  polynomial  of 
degree  M,  the  remainder  will  have  M  coefficients  that  are  either  1  or  0. 

SITE  CONTROLLER  uses  the  CCITT  standard  generating  p>olynomial  x'^  H-  -*-  j:’  -F 1  and 
herKe  d\e  remainder  will  be  16  bits.  It  turns  out  that  a  very  simple  shift  register  plus  XOR  gate 
architecture  can  be  used  to  accomplish  the  polynomial  division,  which  is  why  this  technique 
became  so  popular.  The  benefit  of  using  CRCC  error  detection  is  tinat  two  single  bit  errors  do  not 
cancel  each  other  as  with  XOR,  but  merely  further  corrupt  the  remainder.  The  only  problem 
with  raw  CRCC  is  that  the  message  "all  O's"  will  be  accepted  as  uncor.  upted  since  the 
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remainder  of  0  when  divided  by  anything  is  0.  I  fixed  this  by  using  a  standard  technique  of 
preloading  the  CRCC  register  with  I's,  essentially  prefixing  every  polynomial  to  be  divided  by 
a  standard  header.  Thus,  die  message  "all  O's"  will  not  be  accepted  because  even  a  block  of  0 
data  would  have  a  non-zero  CRCC  remainder  due  to  the  prefixing. 
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7.  Lessons  Learned 

7.1.  Comprehensive  Site  Databases  are  Good 

Although  I  would  like  to  say  that  SITE  CONTROLLER  provides  a  compelling  example  of  ttw 
benefits  of  comprehaisive  site  databases,  it  seems  clear  that  the  best  example  in  recent  memory 
was  provided  by  the  Great  Chicago  Flood  of  April,  1992  (McManamy  1992].  Various 
miscommunications  among  engiiwers  and  a  lack  of  irdormation  exchange  resulted  in  piles  being 
driven  through  the  bottom  of  the  Chicago  River  into  freight  tunnels  underneath.  Imagine  if  the 
pile-driver  operators  were  continually  presented  with  a  computer-geiwrated  cross  section  of  the 
area  in  which  they  were  working,  complete  with  relevant  site  features  such  as  the  freight 
tunnels.  It  seems  likely  that  they  would  then  have  questioned  the  pile  locatioris.  As  tibe 
flooding  of  downtown  Chicago's  basement  cost  society  over  $1  billion,  it  is  probably  the  case 
that  averting  this  one  disaster  would  have  paid  much  of  the  cost  of  automating  America's 
entire  coi\struction  industry. 

.Bringing  together  information  that  is  today  in  separate  programs  or  on  separate  pieces  of  paper 
is  fundamentally  powerful  by  itself.  A  plarming  program  with  hydrology  data  can  trivially 
warn  the  user  that  a  proposed  excavation  will  become  flooded  if  there  is  any  rain.  Keeping 
track  of  utility  lines,  especially  gas  lines,  during  both  design  and  construction  can  save  lives  as 
well  as  millions  of  dollars. 

It  is  important  to  distinguish  between  raw  geometry,  the  kind  of  data  in  traditional  CAD  sys¬ 
tems,  and  full-fledged  objects.  Raw  geometry  consists  of  lines,  text,  polygons,  circles,  etc.  that 
together  communicate  something  meaningful  to  a  human  user.  Full-fledged  objects  represent 
their  real-world  counterparts  in  a  sufficiently  rich  manner  to  permit  computation  about  real- 
world  situations.  For  example,  a  raw  geometry  line/text  combination  that  communicates  "gas 
line"  is  nice  to  have  on  a  blueprint,  but  only  an  object  of  the  class  GAS-LINE  can  conceivably 
cause  a  backhoe-operator  assistant  program  to  declare  a  full  red  alert  when  there  is  a  risk  of 
explosion. 

Once  comprehensive  site  databases  are  available,  analysis  algorithms  will  grow  to  take  ad¬ 
vantage  of  the  data.  Without  the  data,  nobody  will  bother  to  write  software. 

7.2.  Real  Database  Management  would  be  Nice 

The  simplest  computer-aided  civil  engineering  programs  do  not  need  any  kind  of  database.  If  a 
program's  only  ability  is  reading  a  file  of  ( JC,y,  z)  points  and  producing  a  contour  map,  no  inter¬ 
mediate  results  need  be  stored.  SITE  CONTROLLER  builds  complex  data  structures  in  the 
computer's  memory  that  might  be  worth  saving.  Lisp  systems  are  able  to  store  on  disk  an  image 
of  the  memory,  or  "core  dump,"  ttiat  can  later  be  restored.  Users  can  back  up  results  or  store 
intermediate  results  before  trying  radical  ideas.  Further,  by  storing  snapshots  of  the  program 
at  regular  intervals,  it  is  possible  to  later  see  how  the  design  progressed. 
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Because  a  core  dump  saves  everything  that  has  been  added  to  or  changed  in  the  memory  siiKe 
Lisp  was  started,  this  approach  is  extremely  wasteful  of  disk  space.  Cooperation  is  difficult  as 
well.  If  Rebecca  is  working  on  a  design  on  one  workstation,  Rachel  is  unable  to  add  anything  to 
Rebecca's  design  from  another  workstation.  Rachel  would  have  to  come  in  at  night  and  work  on 
Rebecca's  memory  image.  Finally,  a  core  dump  made  on  a  computer  using,  for  example,  a  68000 
microprocessor  might  become  unusable  if  users  switched  to  computers  using  a  RISC  processor 
with  a  different  format  for  numbers. 

Writing  everything  into  a  "moby  file"  (from  Moby  Dick)  is  a  somewhat  better  approach  and 
this  is  what  SITE  CONTROLLER  presently  does.  Users  can  recover  the  exact  state  of  the  system 
whai  die  moby  file  was  written,  just  as  they  did  by  restarting  a  core  dump.  Only  essential  data 
need  be  stored  and  therefore  a  moby  file  may  be  kept  to  a  reasonable  size.  Furthermore,  differ¬ 
ent  sites  may  be  stored  in  different  moby  files  so  that  comparing  projects  is  as  simple  as  reading 
in  multiple  files.  Machine  independence  is  also  achievable. 

Despite  these  advantages,  moby  files  retain  many  of  the  core  dump's  drawbacks.  First,  Rebecca 
and  Rachel  still  can't  cooperate  effectively.  Rebecca  must  write  a  file  then  wait  for  Rachel  to 
read  it,  work  on  die  design,  and  write  it  back  to  disk  before  she  can  work  again.  Second,  all  the 
data  concerning  a  project  must  be  read  even  if  only  a  dny  amount  is  needed.  As  site  models  grow 
to  tens  of  megabytes,  this  may  dramatically  affect  performance.  Third,  no  consistent  journal  is 
kept  of  how  the  design  evolved.  Except  by  laborious  byte-by-byte  comparison  of  moby  files, 
there  is  no  way  to  determine  who  changed  what,  or  when  and  why. 

7.2.1.  Standard  Database  Management  Systems 

A  database  is  structured  information  that  can  be  accessed  or  updated  in  pieces  by  multiple  users. 
Commercial  database  management  systems  (DBMS)  are  highly  evolved  collections  of  programs 
for  solving  standard  business  database  problems.  Their  facilities  are  so  powerful  that  many 
have  been  tempted  to  shoehorn  CAE  data  into  stzindard  DBMS  models. 

Concurrency  control  prevents  simultaneous  updates  by  multiple  users  from  interfering  with  one 
another.  Ensuring  that  updates  occur  in  a  controlled  manner  and  that  the  data  remain  consistent 
have  been  primary  DBMS  concerns  since  the  late  1960's,  when  computerized  airline  reservation 
systems  were  developed.  Reading  and  writing  to  the  database  are  restricted  to  take  place  dur¬ 
ing  atomic  transactions.  The  DBMS  ensures  that  if  a  transaction  cannot  be  completed  for  any 
reason,  the  database  remains  unchanged  from  the  way  it  was  before  die  transaction  commenced. 
When  a  record  is  to  be  upxlated,  the  transaction  first  gets  a  lock,  changes  the  record,  then  re¬ 
leases  the  lock.  While  Rebecca's  transaction  holds  a  lock  on  a  record,  Rachel's  attempt  to  up¬ 
date  is  blocked.  It  is  possible  for  Rebecca's  transaction  to  be  blocked  waiting  for  a  lock  held  by 
Rachel's  transaction  that  is  blocked  waiting  for  a  lock  held  by  Rebecca's  transaction.  This  re¬ 
sults  in  a  deadlock,  and  deadlock  detection  facilities  generally  abort  one  or  both  transactions 
involved. 

Skillful  exploitation  of  standard  DBMS  concurrency-control  facilities  and  techniques  by  a  CAE 
system  enables  users  to  cooperate  on  projects.  Rachel  can  "check  out"  a  portion  of  the  design  and 
work  on  it  while  Rebecca  works  on  some  other  aspect  of  the  problem.  If  Dina  tries  to  make 
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changes  to  Rachel's  portion,  the  database  tells  her  to  wait  until  Rachel  has  "checked  in"  her 
changes.  When  Rachel  checks  in  her  solution,  Rebecca  and  Dina's  working  copies  are  updated 
to  reflect  Rachel's  changes. 

Because  the  first  DBMS  applications  were  financial,  keeping  a  transactions  log  has  always 
been  a  built-in  defense  against  hardware  and  software  unreliability.  A  journal  of  transactions 
is  kept  and  therefore  the  state  of  the  database  at  any  time  is  recoverable  so  long  as  an  initial 
state  and  the  transactions  jourruU  are  retained. 

Commercial  DBMS  devote  much  attention  to  query  mechanisms.  Business  problems  require  fre¬ 
quent  extraction  of  tiny  bits  of  information  from  vast  databases.  The  quest  for  greater  ease  of 
specifying  which  data  are  required  has  spawned  hundreds  of  query  languages.  Query  opti¬ 
mization  algorithms  and  even  special  hardware  have  been  designed  to  improve  database  per¬ 
formance.  CAE  data  scored  in  a  commercial  DBMS  may  be  easily  and  efficiently  accessed  even 
in  ways  not  foreseen  by  the  original  system  desigt>ers. 

In  tt\e  mid-1960's,  IBM  developed  the  hierarchical  data  model  where  everytiiing  is  organized 
into  trees.  A  family's  genealogy  would  fit  nicely  into  the  hierarchical  model.  However,  if  oi« 
wanted  to  also  keep  track  of  all  family  picrucs  and  which  of  the  family  members  had  attended 
each  one,  one  would  be  forced  to  construct  additional  trees  to  represent  tt\at  information.  To 
avoid  duplicating  records  in  these  multiple  trees  and  to  facilitate  the  representation  of  com¬ 
plex  relationships,  hierarchical  database  systems  incorporate  a  variety  of  kludges,  notably 
virtual  records. 

GE  developed  what  became  the  network  data  model  at  roughly  the  same  time.  Data  is  repre¬ 
sented  in  a  directed  graph,  with  each  one-way  link  signifying  a  relationship  between  two 
pieces  of  data.  The  family  picnic  example  above  can  be  represented  more  or  less  directly,  al¬ 
though  one  additional  record  must  be  introduced  for  each  link. 

Both  the  network  and  the  hierarchical  models  require  *e  programmer  to  have  knowledge  of 
the  graph  or  tree  structure.  Queries  are  procedural,  instructing  d\e  DBMS  to  traverse  one  link 
after  another.  This  makes  programs  hard  to  write  and  obscures  their  meaning.  The  relational 
data  model  [Codd  1970)  lends  itself  to  declarative  query  languages.  Instead  of  specifying  how 
to  do  someflung,  the  user  need  only  specify  what  is  wanted.  Relational  algebra  is  a  consistent 
set  of  operations  on  relations  whose  results  are  themselves  relations.  Because  these  operations 
are  closed  under  the  set  of  relations  they  may  be  freely  composed. 

Relational  algebra  has  been  the  basis  of  many  query  languages  for  relational  DBMS.  Of  ttte  re¬ 
lational  languages,  SQL,  developed  in  the  late  1970's  by  IBM,  has  become  the  most  popular. 
SQL  was  intended  to  meet  d>e  needs  of  both  interactive  non-programmers  users  and  experienced 
programmers  and  hence  does  not  fully  satisfy  either  type  of  user:  SQL  cannot  be  the  world's  best 
interactive  query  language  <md  also  an  elegant  data  manipulation  sublanguage  for  conventional 
programming  languages.  Furthermore,  when  SQL  is  grafted  into  host  langiiages,  its  syntax  and 
model  of  computation  often  strike  a  discordant  note.  SQL  itself  is  more  limited  in  power  than 
standard  programming  languages.  One  could  not,  for  example,  write  a  CAE  system  in  SQL. 


85 


Instead/  a  CAE  ^tem  written  in  Lisp  would  include  some  embedded  SQL  commands  to  be 
handed  off  to  the  DBMS. 

Declarative  queries,  ease  of  use,  and  flexibility  in  relational  databases  were  initially 
achieved  at  the  price  of  sluggish  performance.  However,  advances  in  query  optimization  arvd 
computer  hardware  have  made  relational  databases  the  most  practical  solutions  for  most 
business  problems  in  the  early  1990's.  Unfortunately,  the  systems  remain  orders  of  magnitude 
too  slow  to  be  used  by  CAE  programs. 

Many  excellent  textbooks  serve  to  educate  the  future  archivists  of  corporate  America  in  the  art 
of  database  management  [Elmasri  and  Navathe  1989;  Ullman  1988].  Examples  of  ways  in 
which  geometric  ttuxlels  can  be  stored  in  differoit  types  of  databases  are  contained  within 
[Kemper  and  Wallrath  1987]. 

7.2.2.  Object-Oriented  Databases 

Popular  database  models  such  as  relatioruil,  hierarchical  and  network  were  developed  for 
business  data-processing  problems  and  are  well  suited  to  the  simple  objects  and  straightforward 
processing  required  in  the  world  of  business  administraticm.  Transactions  generally  occur 
quickly  and  involve  small  amounts  of  data,  e.g.  "reserve  seat  12A  on  flight  53  on  September  28". 
Schema  nuxlification  is  rare  and  tends  to  affect  a  large  number  of  entries,  e.g.  a  personnel 
database  might  be  modified  to  store  each  employee's  race  to  comply  with  government 
regulations.  Version  control  is  a  non-issue — it  is  not  generally  valuable  to  remember  that 
Employee  674  used  to  be  single  and  is  now  married,  or  that  the  Supervisor  of  Paper  Shuffling  is 
Melissa  Hegel  but  used  to  be  Donald  Frobenius. 

Computer-aided  engineering  gives  rise  to  complex  objects  and  relationships  that  must  be  de¬ 
scribed  obliquely  in  standard  database  systems.  Information  associated  with  an  object  is  often 
spread  around  in  the  database  and  thus  reading  an  object  from  disk  entails  multiple  seeks. 

Since  a  disk  seek  takes  as  long  as  one  million  processor  operations,  minimizing  disk  seeks  is  the 
central  goal  when  striving  for  high-performance  database  systems. 

Transactions  in  CAE  systems  can  take  hours  and  may  involve  megabytes  of  data.  Consider  the 
following  example:  supply  a  surface  to  an  analysis  algorithm,  wait  for  the  water  flow  over  the 
surface  to  be  calculated,  present  that  analysis  to  an  engineer  for  annotation,  and  finally  write 
everything  back  into  the  database  so  that  other  engineers  can  use  the  results  to  keep  structures 
out  of  the  way  of  floods.  Conversely,  transactions  in  CAE  systems  might  take  microseconds.  For 
example,  dragging  a  mouse  across  a  screen  mig^t  result  in  changes  to  dozens  of  portions  of  the 
site  model  and  it  might  be  nice  to  handle  those  changes  as  database  transactions  in  order  to  cap¬ 
ture  the  benefits  of  concurrency  and  version  control.  If  Rachel  and  Rebecca  were  working  closely 
together,  it  might  be  desirable  to  synchronize  their  activities  through  the  database  so  that  ev¬ 
ery  time  Rebecca  dragged  something  around  with  the  mouse,  Rachel  would  see  the  efiects  on 
her  screar. 

Schema  modification  is  a  routine  occurrence  in  a  CAE  system.  An  engineer  may  decide  that  a 
new  type  of  building  block  is  required,  or  that  objects  never  before  lirdced  should  be  associated 
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now.  The  diversity  ot  the  construction  industry  ensures  that  computer-aided  earthmoving  will 
require  flexibUity  in  database  schema.  If  a  job  demands  working  with  asbestos,  a  foreman 
mi^t  need  to  store  information  about  which  workers  smoke  cigarettes  so  that  the  computer 
would  be  able  to  automatically  keep  them  away  from  risky  positions  around  the  site. 

Numerous  object-oriented  database  managen^t  systems  (ODMS)  have  been  developed  recently 
[Cattell  1991;  Bertino  and  Martino  1991]  that  are  much  more  suitable  than  traditioivil  business- 
oriented  database  systems.  At  a  mirumum,  an  ODMS  provides  for  ob/rct  grouping,  storing  in  one 
place  all  the  data  that  pertain  to  one  real-world  or  abstract  entity,  and  object  identity,  unique 
ID  pointers  for  objects  that  are  independent  of  the  values  contained  within  those  objects.  Most 
systems  are  attempts  to  make  persistent  the  object-oriented  features  available  ephemerally  in 
C++,  Common  Lisp  Object  System,  and  Smalltalk.  Consequently,  these  object-oriented  data¬ 
bases  offer  the  same  class  definition,  mheritance,  method  definition,  arul  instance  variable 
storage  features  of  the  object-oriented  programming  language.  Ancillary  query  languages  and 
database  administration  tools  may  be  included,  but  fundamentally  object-oriented  databases  do 
ru>t  require  programmers  to  learn  new  data-numipulation  languages. 

Typifying  the  best  of  the  new  systenrs  is  ObjectStore  [Lamb  1991).  ObjectStore  exploits  existing 
virtual  memory  hardware  and  operating  system  support  to  gain  high  performance  and  trairs- 
parency  to  existing  software.  Persistent  objects  on  disk  are  represented  bit-for-bit  identically  to 
transient  C++  objects  in  memory.  This  kind  of  technique  has  been  used  by  at  least  four  commer¬ 
cial  products  and  is  called  the  disk-image  method.  The  entire  relevant  portion  of  the  database 
in  mapped  into  the  user  process's  virtual  memory  space.  Accessing  an  object  for  the  first  time 
takes  as  much  time  as  handling  a  page  fault,  i.e.,  mostly  however  long  it  takes  to  load  the  page 
from  the  local  disk  or  from  across  the  network.  Subsequent  reads  or  writes  to  a  persistent  object 
occur  at  normal  memory  speed.  Pointers  to  objects  are  ordinary  address  space  pointers. 
ObjectStore  is  able  to  handle  databases  substantially  larger  than  standard  virtual  memory  ad¬ 
dress  spaces,  but  the  extra  long  pointers  are  not  visible  to  user  programs.  Note  that  the  authors 
of  ObjectStore  were  able  to  save  themselves  the  trouble  of  writing  a  data  caching  system — they 
get  it  for  free  from  the  operating  system's  virtual  menwry  code,  which  will  strive  to  keep  the 
data  that  is  most  likely  to  be  needed  in  memory  at  all  times. 

Programs  save  time  and  programmers  save  effort  with  this  architecture  for  several  reasorrs. 
First,  no  translation  need  be  performed  between  the  database  representation  and  the  in-memory 
representation.^  Second,  standard  library  procedures  may  be  used  without  even  recompilation 
to  manipulate  database  objects.  As  far  as  the  library  procedure  is  concerned,  it  is  just  reading  to 
or  writing  from  data  structures  in  memory.  Third,  p>ointers  to  objects  are  dereferenced  by  virtual 
memory  hardware  in  nanoseconds,  rather  than  being  translated  by  software  in  microseconds. 
Firuilly,  the  virtual  memory  system  already  contains  hardware  and  software  support  for 
determining  which  pages  have  been  modified  and  need  to  be  written  back  to  disk. 


^  Conunercial  object  database  systems  otten  incorporate  ambitious  schemes  to  enable  processors 
with  different  number  representations  to  automatically  and  transparently  share  a  database. 
Thus,  if  the  data  were  stored  in  Big  Endian  fashion  and  were  to  be  used  by  a  Little  Endian 
processor,  conversion  would  be  performed  by  the  database  at  some  point. 
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Rather  than  locking  individual  objects,  ObjectStore  locks  virtual  memory  pages.  Thus,  hun¬ 
dreds  of  objects  may  be  locked  with  a  single  swift  operation.  Aldwugh  one  mig^t  conjecture 
that  tlus  would  lead  to  pointless  concurrency  conflicts  since  some  unneeded  objects  are  locked 
along  with  the  ones  dtat  will  actually  be  updated,  in  reality  the  system  is  speeded  up  so  much 
by  not  having  to  keep  track  of  thousands  of  separate  locks  that  transactions  execute  faster  and 
hence  are  less  likely  to  conflict 

Ultimately,  any  choice  among  databases  must  take  performance  into  account.  After  all,  any 
database  management  system  is  capable  of  supporting  any  task  given  a  fast  enough  computer 
arul  enough  extra  work  by  the  programmer  user.  However,  in  the  real  world,  substantially  more 
efficient  execution  makes  the  difference  between  a  practical  solution  and  an  interesting  bit  of 
research.  Benchmarks  on  the  kinds  of  pointer-chasing  done  by  object-oriented  programs  show 
that  ODMSs  in  general  are  about  100  times  faster  than  relational  databases  and  that  there  are 
significant  perfonrumce  differences  among  ODMS  products  [Cattell  and  Skeen  1992]. 

Aldiou^  ObjectStore  solves  many  problems  faced  by  CAE  programmers,  it  also  serves  to  illus¬ 
trate  some  of  the  shortconungs  of  ODMSs.  Using  the  disk-image  approach  yields  dramatic  per¬ 
formance  improvements  but  exacts  a  perudty  in  data  integrity.  A  program  that  can  inadver¬ 
tently  modify  any  memory  location  is  now  capable  of  inadvertently  corrupting  the  database. 
Anyone  who  has  ever  used  a  C  program  on  a  personal  computer  that  mistakenly  wrote  over  the 
operating  system  and  crashed  the  machine  would  probably  have  reservations  about  a  C+*  pro¬ 
gram  managing  critical  financial  data  in  ObjectStore.  (Note:  diere  are  disk-image  object 
databases,  such  as  O2,  that  use  the  disk-image  approach  but  achieve  high  data  integrity  by 
supporting  inherently  safer  languages,  such  as  Lisp  and  Smalltalk.) 

Just  as  C++  is  a  dvowback  to  the  computer  languages  of  the  1960's  and  1970's,  ObjectStore  in 
some  ways  dredges  back  up  limitations  of  hierarchical  and  network  databases:  in  order  to 
achieve  high  performance,  ObjectStore  does  rK>t  by  default  keep  enough  iidormation  about  ob¬ 
jects  to  support  fully  general  declarative  queries.  The  programmer  must  understand  the  struc¬ 
ture  of  the  database  in  order  to  query  it. 

A  final  problem  with  object  database  management  systems  is  that  no  standards  have  evolved  in 
this  world,  either  in  data  models,  query  languages,  or  progranuning  languages.  A  user  of 
ObjectStore,  for  example,  is  shackled  to  that  product  in  a  way  that  an  SQL  progranuner  will 
never  be  limited  to  a  particular  relational  database.  This  is  particularly  distressing  since  no 
existing  product  or  even  research  prototype  provides  a  really  complete  set  of  capabilities. 

While  the  preceding  problems  with  ODMS  are  likely  to  keep  traditional  relational  products 
selling  for  many  years  to  come,  it  is  hard  to  imagine  a  commercially-viable  system  along  the 
lines  of  SITE  CONTROLLER  that  is  not  based  on  some  kind  of  ODMS. 
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7.2.3.  Version  Management  and  Coordinating  Muitipie  Designers 

Committee:  a  group  of  the  unfit  appointed  by  the  unwilling  to  do  the  unnecessary. 

—  Stewart  Harrol 

Version  management  in  CAE  systems  is  a  research  problem.  In  supporting  civil  engineers,  one 
must  keep  track  of  who  modihed  what  and  when  in  the  design,  assure  that  derived  data  is 
marked  invalid  when  the  generating  data  is  modified,  and  try  to  ensure  that  designers  are  kept 
out  of  each  other's  way.  When  the  task  evolves  into  supporting  construction,  die  goal  is  that 
die  state  of  the  site  at  ail  times  should  be  recoverable  from  a  database. 

The  common  substrates  that  are  required  here  are  the  ability  to  track  object  evolution  and  to  ag¬ 
gregate  objects  into  consistent  versions.  Versicm  managemait  has  been  tackled  by  the  design  au¬ 
tomation  community  since  the  early  1980's,  for  electrical  «igineering  [Bhateja  and  Katz  1987]. 
The  general  approach  is  to  add  records  to  the  database  that  describe  aggregations  of  objects,  or 
IS-A-PART-OF  relationships,  and  the  evolutionary  history  of  objects,  or  IS-A-KIND-OF  rela¬ 
tionships.  In  addition,  these  systems  support  automatically  supplying  the  latest  stable  version 
of  an  object  to  most  of  the  designers,  while  allowing  one  or  two  designers  to  continue  working  on  a 
new  version  of  that  object.  Facilities  for  checking-out  and  then  checking-in  objects  are  common, 
as  are  change  propagation  mechanisms. 

Finally,  it  is  often  necessary  to  collect  mutually  consistent  versions  of  objects  in  a  database  into 
a  configuration.  In  a  software  development  system,  this  would  correspond  to  a  release  of  a  new 
version  of  the  product.  In  a  civil  engineering  system,  a  configuration  might  be  one  possible  way 
to  lay  out  a  site  given  a  radically  changed  road  network. 

No  standard  version  model  or  management  system  has  emerged,  but  some  unifying  work  has 
been  done  [Katz  1990]  and  version  management  is  a  standard  feature  of  at  least  six  object-ori¬ 
ented  database  products  [Kim  and  Chou  1988;  Object  Design  1992].  Given  the  practical  realities 
of  the  large  size  of  civil  engineering  projects  and  the  litigious  environment,  it  seems  clear  that  a 
successful  dvil  engineering  design  system  must  have  substantial  version  management  support. 

7.3.  Floating-point  Arithmetic  is  Bad 

Due  to  tile  lackluster  speed  of  the  Lisp  Machine,  I  made  a  Faustian  bargain  with  the  Goddess  of 
Floating  Point  and  eschewed  exact  arithmetic  for  most  geometric  computation.  However,  I  paid 
for  the  speed  She  gave  me  with  terrible  hours  of  debugging  and  digging  for  numerically-stable 
algorithms.  Consider  the  following  problem:  is  a  point  inside  a  triangle? 

It  is  worth  remembering  that  the  standard  equation  of  a  line,  l  =  ax  +  by  +  c  =  0,  has  an 
orientation.  If  we  plug  an  arbitrary  point  (x,,y,)  into  the  left  side  of  this  equation,  a  value  of 
zero  indicates  the  point  is  on  /,  a  negative  value  means  (.Ypyj )  is  to  the  ri^t  of  /,  and  a 
positive  value  means  (Xpy,)  is  to  the  left  of  1.  We  can  get  the  same  line  oriented  in  tiie 
opfiosite  direction  simply  by  multiplying  the  equation  through  by  a  negative  constant. 
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Figure  7.1  Oriented  lines  arranged  around  the  edges  of  a  triangle.  Points  to  the  rig^t  of 
all  three  lines  are  inside  the  triangle. 

If  we  build  appropriately  oriented  lines  coUinear  with  the  edges  of  a  triangle,  we  can 
determine  query  point  ( p^)  inclusion  by  plugging  tl^  point's  coordinates,  into  all  three 

lii>e  equations.  If  the  results  all  have  the  same  sign,  ttien  is  in  the  triangle  (see  Figure  7.1). 
Consider  the  computation  being  performed  here:  ax^  +  by^  +  c.  If,  for  example,  the  summands 
ax^  and  by^  are  large,  then  the  contribution  of  c  may  be  nil  if  it  is  combined  with  by^  first.  I 
struggled  with  what  I  thought  was  a  subtle  bug  in  a  geometry  algorithm  for  several  hours.  1 
fiiuiUy  zeroed  in  on  a  triangle  that  was  reporting  p^  as  outside  of  the  triangle  even  thou^ 
zooming  in  revealed  p,to  be  just  barely  inside.  When  Jim  Little  heard  about  this,  he  sagely 
noted  that  "Iiuier  product  accumulation  frequently  requires  double  precision  arithmetic." 

About  10%  of  my  time  working  on  the  core  of  9TE  CONTF  -i  liR  was  devoted  to  hunting  down 
bugs  created  by  my  unjustified  faith  in  floating  point  numbers  and  then  searching  for 
alternative  algorithms.  Faster  machines  and  floating  point  implementations  with  more 
precision  simply  postpone  the  day  of  reckoning.  Exact  arithmetic,  i.e.,  rational  numbers,  is  the 
oiUy  long-term  soluticm  that  will  give  anyone  confiderKe  in  complex  geometric  computation 
systems. 

7.4.  Programming  Environments  Matter 

In  ttie  "good  old  days"  (for  programmers,  that  is),  computers  were  expensive  and  so  were  pro¬ 
grammers.  Thus,  in  the  early  1970's,  a  corporation  might  spent  $5(X),000  or  more  on  a  mainframe 
and  $50/hour  or  more  for  really  skilled  programmers.  The  Mythical  Man-Month  convinced 
software  development  managers  that,  even  with  all  the  money  and  programmers  in  the  world, 
d^e  growing  complexity  of  ambitious  computer  systems  made  success  doubtful  [Brooks  1975]. 
When  it  was  observed  that  computers  were  getting  cheaper  and  programmers  more  expensive, 
the  industry  scrambled  to  make  precious  programmers  more  productive.  The  apotheosis  of  d\e 
programmer  was  best  evidenced  by  the  MIT  Lisp  Machine,  a  $1(X),0(X)  (in  1980!)  personal 
computer  made  by  and  for  some  of  the  world's  best  programmers.  The  reasoning  behind  the  Lisp 
Machine  was  this:  rather  than  hire  ten  mediocre  programmers  who  will  spend  most  of  their 
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time  fitting  low-level  languages  and  stepping  on  each  other's  toes,  hire  orw  good  programmer 
with  a  Lisp  Machine  who  can  solve  the  whole  problem  by  himself  in  a  fraction  of  the  time. 

However,  the  1980's  brou^t  two  simultaneous  revolutions:  1)  the  dumping  on  the  market  of 
thousands  of  people  with  bachelor's  degrees  in  computer  scioKe,  arwJ  2)  a  collapse  in  the  price 
of  computCT  power.  By  1990,  the  world  looked  very  different  from  what  anyone  imagined  in 
1970.  A  corporation  might  still  spend  $500,000  for  a  mainframe  but  the  programmers  only  cost 
$15/hour  in  1970  dollars  (i.e.,  after  adjusting  for  inflation).  Mostly,  however,  companies  buy 
inexpensive  prepackaged  software  on  inexpensive  personal  computers  and  don't  hire 
progranuners  at  all. 

Occasionally  programming  is  unavoidable,  either  for  a  custom  solution  or  because  a  company 
wishes  to  sell  prepackaged  software.  Conventional  wisdom  today  calls  for  a  large  group  of 
low-paid  programmers  using  1960's-style  tools  such  as  UNIX,  MS/DOS,  and  C.  Any  competent 
computer  scientist  could  prove  that  this  approach  simply  caimot  work,  yet  at  first  glance  it 
appears  to  and  has  produced  billions  of  dollars  in  profits  for  many  corporatior«. 

There  are  a  variety  of  reasons  for  the  success  of  the  "horde  of  C  hackers"  approach.  One  of  the 
most  important  is  that  programmers  today  are  solving  problems  that  were  first  solved  many 
years  ago.  For  example,  UNIX  was  developed  in  the  1970's  with  a  subset  of  features  of  1960's 
operating  systems,  most  notably  MULTICS;  Microsoft  Word  was  an  mcremental  improvement  of 
MacVirite,  which  was  in  turn  inspired  by  work  done  at  Xerox  PARC  in  the  1970's;  PC  networks 
are  reimplementations  of  systems  foat  were  developed  on  mainframes  in  the  1960's  and  1970's; 
most  database  systems  are  rehashed  versions  of  old  IBM  products.^  When  one  has  a  concrete 
idea  of  what  the  completed  system  should  do,  one  is  seldom  forced  to  risk  introducing  bugs  by 
modifying  structures. 

Another  reason  the  "horde  of  C  hackers"  approach  has  worked  remarkably  well  is  that,  al¬ 
though  ttie  resultant  software  is  rife  with  bugs,  most  users  have  no  experience  with  anything 
better.  When  an  MBA's  Macintosh  Quadra  crashes  due  to  a  C  programmer's  error  in  Microsoft 
Excel,  he  doesn't  say  "I  remember  back  in  1978  that  my  VAX  11/780,  with  only  one  tenth  the 
processing  power  of  this  machine,  had  memory  protection  between  processes  so  that  a  bug  in  one 
program  couldn't  corrupt  the  operating  system  or  other  applications."  Rather,  he  is  likely  to 
say,  "Well,  it  is  still  easier  than  using  pencil  and  paper." 

Finally,  big  C  programming  projects  succeed  because  they  simply  aren't  that  big.  The  biggest, 
most  ambitious  programs  of  the  1970's  would  still  be  big,  ambitious  programs  today.  For  exam¬ 
ple,  hAACSYMA,  a  circa  1970  Lisp  program,  is  still  the  world's  most  powerful  computer  algebra 
system,  despite  the  hundreds  of  man-years  and  massively  powerful  new  computers  foat  have 
gone  into  making  competitive  C  programs.  Significant  computer  power  was  not  widely  avail¬ 
able  in  1970,  so  only  a  tiny  number  of  people  remember  using  really  big  programs  two  decades 
ago  and  therefore  users  believe  today's  programs  to  be  remarkably  big  and  ambitious. 


copy  of  a  beautiful  thing  is  always  an  ugly  thing.  It  is  an  act  of  cowardice  in  admiration 
of  an  act  of  energy.  —  R6my  de  Gourmont.  (This  is  my  favorite  description  of  C++.) 
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Computer-aided  civil  engineering  is  different.  Because  the  Global  Positioning  System  is  new 
and  because  sufficiently  powerful  computers  are  only  now  cheap  enough  for  dvil  engineers, 
there  are  no  mainframe  or  minicomputer  systems  that  can  serve  as  models  for  what  PC  software 
should  do.  For  example,  nobody  knows  a  good  way  to  capture  a  construction  plan  frtHn  a  user. 
Any  program  that  is  duown  out  into  the  real  world  is  likely  to  be  thrown  right  back  witt\  hur 
dreds  of  deficiencies  rtoted.  If  adding  features  to  address  those  deficiencies  introduces  bugs,  an¬ 
other  important  difference  of  civil  engineering  is  going  to  make  itself  apparent. 

Users  may  rvjt  be  so  forgiving  of  bugs  in  systems  whose  errors  can  <jause  the  loss  of  millions  of  dol¬ 
lars  or  even  human  lives.  Rebooting  a  PC  because  the  word  processor  or  spreadsheet  crashed  the 
machii\e  is  an  aimoyance.  Bugs  in  complex  computer-aided  VLSI  design  systems  may  delay  a  in¬ 
tegrated  circuit's  introduction  to  market,  but  would  be  unlikely  to  cost  as  much  as  the  $1  billion 
lost  in  the  Chicago  flood.  Anyone  roasted  in  a  Ford  Pinto  would  probably  argue  that  mechani¬ 
cal  engineering  errors  can  be  just  as  deadly  as  civil  engineering  errors,  but  mechanical  systems 
may  be  tested  exhaustively  before  an  investmott  is  made  in  mass-production  and  dramatic  fail¬ 
ures  are  consequently  rare.^  By  contrast,  civil  works  are  normally  one-of-a-kind  and  realistic 
tests  are  often  impossible.  Thus,  the  Tacoma  Narrows  suspension  bridge  blows  down,  costing 
tens  of  millions  of  dollars,  and  the  Kansas  City  Hyatt  bridge  collapses,  killing  scores  of  people. 

Finally,  computer-aided  civil  engineering  is  going  to  require  enormous  systems,  much  larger 
than  the  "mostly  working"  C  programs  currently  being  developed,  with  the  added  kicker  that 
they  must  operate  in  real  time.  A  system  incapable  of  real-time  response  and  error-free  opera¬ 
tion  will  be  relegated  to  supporting  civil  engineering  design  only,  a  tiny  portion  of  the  industry. 
Construction  is  where  the  dollars  are;  models  must  be  comprehensive  and  queried  and  updated 
in  real  time. 

The  problems  seen  by  developers  of  the  1960's  and  1970's  most  ambitious  software  systems  have 
never  been  solved  and  they  will  come  back  to  haunt  developers  of  computer-aided  civil  engi¬ 
neering  systems  in  'the  1990's.  Obvious  problems  include  the  following:  1)  inherent  complexity, 
2)  inherent  dynamism  of  data  structures,  3)  maintaining  extensibility  so  that  unenvisioned  ca¬ 
pabilities  may  be  added,  and  4)  maintaining  high  performance  despite  massive  amounts  of 
data  and  complex  geometric  problems. 

An  army  of  C  hackers  will  not  be  able  to  surmount  these  problems.  They  will  sp)end  most  of 
their  time  stepping  on  each  other's  toes,  fighting  their  storage  allocation  bugs,  ripping  apart 
the  system  to  add  new  features,  and  digging  out  from  under  the  sluggishness  of  their  ad  hoc 
memory  management  algorithms.  SITE  CONTROLLER  shows  that  a  small  group  of  program¬ 
mers,  working  with  good  tools  such  as  automatic  storage  management,  a  modem  object  system, 
higher-order  procedures,  metalinguistic  abstraction,  exact  arithmetic,  and  a  concise  language, 
has  a  chance  of  overcoming  the  management-of-complexity  and  extensibility  problems  inherent 
in  this  area. 


*  In  the  case  of  the  Pinto,  the  problem  had  been  noted  and  debated  within  the  company  well 
before  anyone  was  incinerated — that  the  company  continued  to  use  the  design  for  reasons  of  cost 
was  a  failure  of  management,  not  of  engineering. 
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7.5.  Algorithm  Animation  Aids  Debugging 

Everyone  knows  that  damage  is  Jane  to  the  soul  by  bad  motion  pictures.  —  Pope  Pius  XI 

Bug-rid<ien  programs  make  their  mistakes  instantly,  quietly,  and  secretly.  Tools  that  allow 
programmers  U)  watch  execution  proceed  at  a  human  pace  animate  algorithms.  The  crudest 
form  of  algorithm  animation  is  the  stepper.  Stepping  through  a  program,  a  programmer  gets  to 
see  each  piece  of  code  before  it  executes,  complete  with  the  values  of  local  variables  and  ar¬ 
guments.  Only  after  the  programmer  takes  a  positive  action,  such  as  typing  a  character,  does 
the  code  actually  execute.  Since  a  typical  computer  can  execute  13  million  instructions  per  sec- 
orvi  and  a  typical  human  can  type  ru)  more  than  500  characters  per  second,  this  process  slows 
down  the  program  by  a  factor  of  at  least  20,000  and  is  therefore  impractical  unless  the  pro¬ 
grammer  already  has  the  problem  rteirowed  dc  wn  to  a  fragment  of  a  big  system.  Thus,  it  was 
only  on  occasion  that  I  was  ordy  able  to  gain  insight  inf''  bue-riagued  portions  of  SITE 
CONTROLLER  by  using  the  Lisp  Machirte  stepper. 

Algorithm  animation  is  an  active  research  area,  spurred  to  some  extent  by  frustration  with  the 
fact  that  the  programmer  has  gained  alnnost  nothing  from  the  hardware  revolution  that  gave 
every  computer  user  a  big  screen  filled  with  wiruiows  and  graphics.  Even  powerful,  muldwin- 
dow  programming  envirorunents  such  as  the  MIT  Lisp  Machine,  Smalltalk  (Goldberg  and  Robson 
1983],  and  Cedar  [Teitelman  1984],  basically  use  graphics  workstations  as  multiple  ASCII  ter¬ 
minals.  If  only  those  windows  could  be  filled  with  different  simultaneousJv-updated  graphi¬ 
cal  views  of  an  algorithm  in  action,  the  programmer  could  debug,  the  studer  l  might  learn,  and 
the  customer  would  be  impressed. 

Deciding  what  information  to  present  and  at  what  stage  in  an  algorithm's  execution  to  update 
that  information  requires  positive  action  on  the  part  of  the  programmer.  The  programmer 
normally  must  also  decide  how  information  is  to  be  presented,  since  standard  programming 
environments  provide  no  support  for  the  graphical  display  of  even  fairly  basic  data  structures, 
such  as  arrays,  linked  lists,  and  hash  tables. 

Consider  a  program  that  stores  data  in  a  hash  table.  An  animation  of  this  program  might 
include  the  folloving: 

•  a  window  showing  the  source  code  with  the  currently  executing  line  highlighted 

•  a  window  showing  all  the  buckets  of  the  hash  table  and  their  contents.  If  there  are 
too  many  buckets,  a  view  of  the  entire  table  shows  a  simple  schematic  drawing, 
perhaps  with  one  pixel  turned  on  for  each  entry  in  a  bucket.  However,  zooming  in  would 
reveal  detail  and  the  bucket  contents  would  be  more  fully  described. 

•  windows  showing  input  and  output  data  marching  along  with  program  execution 

•  meters  showing  information  derived  from  the  program's  data  structures  and  execution, 
such  as  hashing  efficiency  and  average  access  time 

By  watching  this  animation,  a  programmer  would  instantly  be  alerted  to  a  bad  hashing 
algorithm  (clumps  of  data  would  collect  in  just  a  few  buckets).  If  the  clustering  problem  were 
related  to  the  input  data,  that  would  be  visible  as  well. 
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Geometric  algorithms  lend  themselves  to  animation  in  more  obvious  ways.  A  plane-sweep 
Delaunay  triangulation  algorithm  comes  to  life  as  the  edges  between  points  are  drawn  as  the 
algorithm  builds  the  final  data  structure  [Gillett  1988].  Any  algorithm  that  walks  through  a 
geometric  data  structure  should  be  able  to  successively  highlight  each  edge  and  vertex  consid¬ 
ered  and  give  the  programmer  a  printed  report  on  what  conclusions  are  being  made.  All  the  ge¬ 
ometric  algorithms  in  SITE  CONTROLLER  are  implemented  with  some  self-arumation  capabil¬ 
ity.  This  is  because  I  discovered  quite  early  that  such  programs  invariably  either  work  per¬ 
fectly  the  first  time  or  are  impossible  to  debug  without  periodic  graphical  snapshots  of  their 
state.  If  a  program  works,  the  animation  capability  will  be  useful  in  training  programmers  new 
to  the  project.  If  a  program  fails,  the  animation  capability  will  make  debugging  painless. 
Depending  on  the  programming  language,  there  are  numerous  conv«uent  ways  of  ensuring  that 
tt\e  animation  hooks  do  not  degrade  performance  or  increase  program  size  when  not  in  use. 

The  1990's  will  be  a  period  of  evolution  for  algorithm  animation  programming  tools.  Toolkits 
for  animating  standard  data  structures  and  interacting  with  arbitrary  animations  should 
evolve  from  academic  experiments  into  standard  commercial  tools.  A  lucid  overview  of  the 
topic  and  a  description  of  Balsa-II,  a  pioneering  system,  are  contained  in  (Brown  1988].  Tango,  a 
spiritual  descendant  of  Balsa  that  is  less  restrictive,  is  described  concisely  in  [Stasko  1990]. 

The  bottom  line  is  that  ad  hoc  algorithm  animation  saved  me  hundreds  of  hours  in  the  devel¬ 
opment  of  SITE  CONTROLLER;  better  and  more  complete  algorithm  animation  should  greatly 
facilitate  die  development  of  more  complex  successor  systems. 
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8.  Conclusion 


The  time  is  ripe  for  computer-aided  civil  engineering  and  especially  computer-aided 
eardunoving.  SITE  CONTROLLER  demonstrates  that,  with  so  much  iidrastructure  in  place,  a 
comparatively  tiny  amount  of  work  suffices  to  yield  enormous  productivity  dividends. 

Let's  look  back  at  the  dvee  components  menti(med  in  Section  1;  a  central  computer  system  such 
as  SITE  CONTROLLER;  a  location  system;  and  on-vehicle  computers.  Recent  advances  in 
differential  Global  Positioning  System  receivers  have  made  it  abundantly  clear  that  the 
precision  required  for  earthmoving  will  be  available  soon  in  rugged,  inexpensive  packages. 
Research  and  development  activities  at  machine  vendors  like  Caterpillar  indicate  that  the 
on-board  computer  and  control  systems  required  by  SITE  CONTROLLER  can  be  designed  and 
manufactured  internally  by  any  of  the  major  An^ican,  European  or  Japanese  manufacturers. 

My  work  on  SITE  CONTROLLER,  study  of  the  literature,  and  years  of  software  development 
experience  lead  me  to  believe  ttiat  a  few  dozen  good  programmers,  supported  by  the  best  current 
tools,  would  be  able  to  deliver  practical,  reliable  software  for  every  part  of  an  integrated 
computer-aided  earthmoving  system. 

Cutting  the  cost  of  earthworks  by  half  is  an  entirely  reasonable  goal.  Cutting  ti\e  cost  of 
hazardous  waste  site  remediation  by  a  factor  of  ten  is  probably  an  essential  goal.  Such 
dramatic  cost  reductions  would  change  tfie  shape  of  the  planet  and  have  an  immediate  effect  on 
the  lives  of  billions.  All  for  the  price  of  a  few  lines  of  code. 
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Glossary 


CAD  computer-aided  drafting  or  computer-aided  design,  programs  primarily  intended  to 
support  draftsmen. 

CAE  computer-aided  engineering,  a  newer  getve  of  programs  with  more  powerful  models  of  the 
underlying  problems,  primarily  intended  to  support  engineers. 

CAR  built-in  Lisp  procedure  that  returns  the  first  element  of  a  list.  This  acronym  is  from  a 
1950's  M.I.T.  implementation  of  Lisp  on  the  IBM  704:  "contents  of  address  register." 

CDR  built-in  Lisp  procedure  that  returns  the  portion  of  a  list  that  follows  its  first  element. 
CDR,  pronounced  "could-er"  is  the  complement  of  CAR,  and  was  originally  "contents  of 
decrement  register." 

class  definition  for  a  type  of  object  in  an  object-oriented  programming  system.  Thus,  HUMAN  is 
a  class,  and  the  individual  "Naomi  Rosenblum"  is  an  instance  of  that  class.  Actually,  Naomi 
would  probably  be  represented  as  an  instance  of  die  subclass  WOMAN, which  would  inherit 
from  HUMAN,  which  would  in  turn  inherit  from  the  superclass  ANIMAL. 

CONS  built-in  Lisp  procedure  that  glues  two  Lisp  objects  togedier,  short  for  "construct."  With 
this  fimdamental  mechanism,  it  is  possible  to  represent  lists,  trees,  and  other  more  complex 
data  structures. 

convex  hull  the  smallest  convex  polygon  that  contains  a  set  of  pioints  (in  the  plane  for  Site 
Controller,  although  this  concept  generalizes  to  higher  dimensions).  Imagine  stretching  a 
rubber  band  around  a  set  of  pins  stuck  into  a  board. 

Delaunay  triangulation  (of  a  set  of  points  5)  a  cormection  of  the  points  in  S  such  that  the 
convex  hull  of  5  is  broken  up  into  triangles  and  those  triangles  are  as  close  to  equilateral  as 
possible.  The  dual  of  the  Voronoi  diagram. 

dragline  machine  that  throws  a  bucket  in  front  of  itself  and  then  drags  it  back  via  steel  cables, 
thus  filling  the  bucket  with  earth  and  rock.  Generally  used  at  surface  mines  to  expose  mineral 
seams. 

GPS  global  position  system  of  satellites  launched  by  die  US.  military  that  enable  one  to  fix 
one's  position  in  three  dimensions  anywhere  in  the  world  to  high  accuracy. 

hypertext  is  a  directed  graph,  where  each  node  contains  some  amount  of  text  or  other  informa¬ 
tion.  Users  are  able  to  get  to  a  new  node  by  selecting  a  word  or  phrase  at  the  current  node. 

instance  is  a  particular  example  of  a  class  in  an  object-oriented  program.  Thus,  "Pinto  with 
vehicle  identification  number  74I23BURN97FAST'  is  an  instance  of  the  class  FORD-PINTO. 
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kludge  an  inelegant  and/or  expedient  solution  to  a  problem,  analogous  to  patching  a  leaky 
radiator  with  duct  tape. 

leaves  terminal  elements  of  a  tree  data  structure,  i.e.,  ones  that  have  no  children. 

Lisp  Machine  powerful  personal  computer  developed  at  M.I.T.  in  the  late  1970's  to  facilitate 
rapid  software  development,  especially  in  the  Lisp  programming  language. 

metalinguistic  abstraction  defining  a  new  formal  language  to  facilitate  the  solution  of 
programming  problems  in  a  particular  domain. 

message  and  method  prinutive  concepts  in  the  Flavors  object-oriented  programming  system.  A 
message  is  the  name  of  a  generic  operation  and  it  is  sent  to  an  object.  When  an  object  receives  a 
message,  it  handles  it  widi  a  collection  of  appropriate  methods  that  have  been  defined  by  its 
class  or  its  superclasses. 

MIPS  millions  of  instructions  per  second,  a  rough  measure  of  a  computer's  computational 
capability. 

mixin  a  class  whose  characteristics  do  not  neatly  divide  a  space  and  in  fact  are  orthogonal  to 
those  of  odier  mixins.  Thus,  SOCIAL- ANIMAL  would  properly  be  a  mixin  since  it  would  be  a 
useful  component  of  classes  for  monkeys,  dogs,  wolves,  whales,  lions.  By  contrast  MAMMAL, 
PRIMATE,  CAT,  etc.  would  not  be  appropriate  mixins. 

nodes  intermediate  elements  in  a  tree  or  network  data  structure. 

orders  of  growth,  e.g.  ),(?(« log n),0(n),  etc.  Formally  defined,  0{g{n))  is  the  set  of 

functions  f{n)  such  that  there  exist  positive  constants  c  and  /Jq  such  that  0  £  f{n)  <  cg(n) 
for  all  n  >  /!(, .  Asa  pracical  matter,  what  people  mean  when  d\ey  say  a  function  is  0(n^ )  is 
that  its  ruiming  time  (or  sometimes  space),  as  the  amount  of  data  gets  large,  grows  no  faster 
than  the  function  . 

quadtree  data  structure  for  organizing  two-dimensional  space  so  that  searches  can  be  performed 
in  0(log4  n)  time.  Every  node  in  the  tree  has  four  children,  hence  "quad,"  and  each  child  is 
allocated  cme  quarter  of  the  space  owned  by  its  parent. 

subclass  more  specific  type  in  an  object-oriented  programming  system.  Thus,  IVY-LE AGUE- 
SCHOOL  is  a  subclass  of  UNIVERSITY. 

superclass  less  specific  type  in  an  object-oriented  programming  system.  Thus,  DOG  is  a 
superclass  from  which  the  class  HUNTING-DOG  might  inherit. 

surveyed  point  SITE  CONTROLLER  data  structure  representing  a  point  whose  elevation  is 
known.  This  is  the  fundamental  input  to  SITE  CONTROLLER  surface  models. 
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tree  data  structure  shaped  like  the  plant  of  the  same  name,  with  a  root  at  the  tx)ttom,  branches 
that  divide  at  nodes  and  terminate  in  leaves.  Trees  are  useful  for  orgaiuzing  daU  so  that 
searching  can  be  performed  in  0(log  n)  time. 

Vrnoncd  polygon  (of  a  point  )  the  locus  of  points  closer  to  p,  than  to  any  other  point  in  the  set 
p^,p2,K  ,Pf,.  In  the  plane,  this  locus  ends  up  being  a  polygon  around  p^ . 

Voronoi  diagram  (of  a  set  of  points  S)  a  partition  of  the  plaive  into  polygons,  each  one 
surrounding  one  of  the  points  in  S .  The  dual  of  the  Delaunay  triangulation. 
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